Skip to main content

1. Prepare the server

In short. You install Docker and some tools, and open only the ports that the app needs. You point your domain to the server and create your deploy and signing keys. Then you install the small scripts that run each deploy. At the end, the server accepts only releases that you signed, and only through your deploy key. You do this page once.
Log in to the server with your own administrator account. Use the provider’s web console or SSH. The overview page explains the words and the placeholders, for example <your-domain>. Each command block says where to type it: on the server or on your computer.

Step 1. Check that Polymarket allows the server’s location

  1. On the server, ask Polymarket if it permits this location:
    If the server says curl: command not found, type sudo apt install curl and try again.
  2. Read the answer. It must contain "blocked":false.
  3. If the answer contains "blocked":true, stop. This server cannot trade. Rent a server in a different region.
  4. On the server, make sure that no proxy is set. Type each command. Each command must show nothing:

Step 2. Install the software

  1. On the server, install Docker. Follow Docker’s own instructions: https://docs.docker.com/engine/install/. You need Docker Engine 27 or later, with the compose and buildx plugins. Docker’s instructions install the two plugins.
  2. On the server, install git, age, rsync and the firewall:
  3. On the server, turn on the automatic clock sync:
Is it working?

Step 3. Open only the ports the app needs

Ports 80 and 443 serve the site. Port 22 is SSH. Only your computer and the backup machine can use port 22. CAUTION: Make sure that <your-ip> is correct before you type sudo ufw enable. An incorrect address locks you out of SSH. If this occurs, use the provider’s web console to correct the rule. On the server, type these commands in this order:
If your provider has a firewall in its control panel, set the same rules there. Is it working? On the server, sudo ufw status shows Status: active and the ALLOW rules for ports 22, 80 and 443.

Step 4. Point your domain at the server

At your DNS provider, add these two records for <your-domain>: Add an AAAA record only if these two conditions are true:
  • The server has an IPv6 address.
  • You will do the IPv6 check (S6) in the security checklist.
Is it working? On your computer, dig +short <your-domain> shows <server-ip>. A new record can take up to 1 hour to show.

Step 5. Create the two service accounts

The deploy account receives the deploy commands. The sesame-backup account lets the backup machine read the encrypted backups. On the server:
WARNING: Do not add deploy to the docker group. Access to Docker gives full control of the server.

Step 6. Move SSH keys to root-owned files

After this step, no account can add a key for itself. Your own login must use an SSH key, because Step 11 turns off password logins. If you log in with a password now, type ssh-copy-id <admin>@<server-ip> on your computer first. On the server:
The cat line copies your own key, so your login continues to work after Step 11.

Step 7. Create the deploy key

  1. Put the security key into your computer.
  2. On your computer, create the deploy key:
    If you do not have a security key, use the command below. Set a passphrase when it asks.
  3. On your computer, show the public key. Copy the line that it shows:
  4. On the server, open the key file of the deploy account:
  5. Write one line: the start below, then a space, then the public key that you copied.
    For a key with a passphrase, remove verify-required, from the start. That public key starts with ssh-ed25519.
  6. Save the file and close the editor.
The from="<your-ip>" part accepts the key only from your computer’s address. If that address changes, change it in this file. WARNING: Do not load this key into an ssh-agent (ssh-add). The deploy script refuses a key that has no passphrase and is not on a security key.

Step 8. Set up release signing and sign the first release

The server installs only release tags that you signed. Do all of this step on your computer.
  1. Create a signing key. Set a passphrase when it asks:
  2. Tell git to sign with this key:
  3. Create your list of allowed signers. Keep it outside the repository:
  4. Show the list and copy the line. The server needs it in Step 9:
  5. Go to your copy of the repository. Sign a tag on the reviewed commit that you want to run. Each release tag name must start with release-:
  6. Send the tag to the repository:

Step 9. Create the server’s deploy settings

  1. On the server, create the settings folders and files:
  2. Open the list of allowed signers:
  3. Paste the line from Step 8, item 4. Save the file and close the editor.
  4. Open the deploy settings:
  5. Write these four lines with your values. Save the file and close the editor.
For a private repository, see Private repository.

Step 10. Install the server scripts

These commands get your signed tag and check its signature. Then they install the three parts that the deploy uses:
  1. On the server, become root:
  2. Get the tag and check its signature:
    The last line must show Good "git" signature. If it does not, stop. Do Step 8 and Step 9 again.
  3. Install the scripts and the timer:
  4. Open the access rule for the deploy account:
  5. Paste these two lines. They are the content of deploy/sudoers.example. Save the file and close the editor.
  6. Remove the temporary files and leave the root shell:
Is it working? On the server, sudo -l -U deploy shows /usr/local/sbin/sesamectl and no other command.

Step 11. Lock down SSH

This step turns off password logins and root logins. It also limits each of the two service accounts to its one task.
  1. On the server, copy the SSH settings from the tag:
  2. Open the file:
  3. On the AllowUsers line, replace admin with <admin>. Save the file and close the editor.
  4. Check the settings and load them:
  5. Keep your current session open. Open a new terminal on your computer and log in to the server again. Close the first session only after the new login works.
Is it working? On the server, sudo sshd -T | grep -i '^passwordauthentication' shows passwordauthentication no. If it shows yes, a different file in /etc/ssh/sshd_config.d/ turns password logins on. Remove that line from that file and do item 4 again.

Step 12. Record the server’s fingerprint

  1. In the provider’s web console, not over SSH, show the server’s fingerprint:
  2. Write down the part that starts with SHA256:.
  3. On your computer, connect to the server by its domain name:
  4. ssh shows an ED25519 key fingerprint and asks if you want to continue. Compare it with the fingerprint from item 2.
  5. If the two fingerprints are the same, type yes. If they are different, type no and stop. Do not deploy to this server.
  6. Type exit to close the connection.
After this step, the deploy refuses a server with a different fingerprint. The backup machine does the same comparison in 3. Backups.

Is it working?

On your computer, send a command that the server must refuse. When ssh asks, type the PIN of the security key and touch the key. For a key file, type the passphrase.
The result is sesame-deploy-shell: refused: not an allowed sesamectl command. If you see a different message, see Troubleshooting. Previous: Overview · Next: 2. First deploy