How to Deploy Twenty CRM on a VPS

#Install Twenty

Twenty publishes an official docker-compose.yml and a matching .env.example in the twenty-docker package of its repo. Pull both down, then generate the two secrets the compose file needs and append them to .env:

copymkdir twenty && cd twenty
wget -O docker-compose.yml https://raw.githubusercontent.com/twentyhq/twenty/main/packages/twenty-docker/docker-compose.yml
wget -O .env https://raw.githubusercontent.com/twentyhq/twenty/main/packages/twenty-docker/.env.example
echo "PG_DATABASE_PASSWORD=$(openssl rand -hex 24)" >> .env
echo "ENCRYPTION_KEY=$(openssl rand -base64 32 | tr -d '\n')" >> .env

A couple of things worth understanding about those two values before you move on:

• PG_DATABASE_PASSWORD is the password Twenty's Postgres container is initialized with, and the one the server and worker use to reach it. It only matters on first boot — change it later and the running database won't match it anymore. Use openssl rand -hex, not -base64, here: Twenty's own .env.example warns this password must have no special characters, and base64 output can include + and /, which break the connection string the server builds — the failure mode is ugly (a psql: invalid integer value ... for connection option "port" loop) and only shows up on the unlucky passwords that happen to contain one of those characters.
• ENCRYPTION_KEY is the key Twenty uses to encrypt sensitive data at rest (tokens, secrets stored in the app) and to sign sessions. Treat it like a root password: back up .env somewhere safe right now. Lose this key and encrypted data becomes unrecoverable; change it later on a running instance and existing sessions and encrypted values break.

.env.example ships more variables than just those two — most are fine at their defaults for a first deploy, but set SERVER_URL to the address you'll actually reach the app on before you go live (https://crm.example.com once you've wired up the domain below, or http://SERVER_IP:3000 if you're only testing). Twenty uses it to build links, API URLs, and outbound email content, and the default only works for local testing.

Bring the stack up:

copydocker compose up -d || true

The server runs ~180 database migrations against Postgres on first boot, and that routinely takes longer than the server's own healthcheck retry budget — so this first docker compose up -d commonly exits with dependency failed to start: container twenty-server-1 is unhealthy, and the worker container never starts. That's expected, not a failed deploy (the || true keeps the command from erroring out): the server keeps retrying in the background (its compose entry sets restart: always) and finishes the migrations on its own. Watch it, then start the worker once it reports healthy:

copyuntil docker compose ps server | grep -q '(healthy)'; do sleep 5; done
docker compose up -d --no-recreate

Use --no-recreate so the second up starts the missing worker without bouncing the already-healthy server — a plain up -d can recreate the server and reset its healthcheck clock, failing the same way again on a warm first boot. You should see db, redis, server, and worker all Up. Once the server's log settles, it's reachable at http://SERVER_IP:3000.

#HTTPS + domain

Testing over http://SERVER_IP:3000 is fine for a first look, but a CRM holding real customer data should be served over HTTPS on a real domain — plain HTTP means credentials and session cookies cross the network in the clear. Twenty's official compose file doesn't bundle a reverse proxy, so add one.

The simplest path is Automatic HTTPS with Caddy, which fetches and renews Let's Encrypt certificates for you with a couple of lines of config. Point an A record for your hostname (say crm.example.com) at the server's public IP, then have Caddy reverse-proxy that hostname to 127.0.0.1:3000. Once DNS resolves, Caddy issues a certificate automatically and Twenty is live on HTTPS.

After DNS and Caddy are both working, go back and set SERVER_URL in .env to your real https://crm.example.com address if you hadn't already, then restart so the server picks it up:

copydocker compose up -d

A mismatched SERVER_URL is the single most common misconfiguration on a first deploy — get it wrong and links in emails, the API base URL, and file download links all point at the wrong place.

#First-run setup

Load https://crm.example.com (or http://SERVER_IP:3000 if you're still testing) in a browser. Twenty shows a sign-up screen on a fresh install.

Create your account and workspace immediately. As with most self-hosted tools, the sign-up screen is open to anyone who can reach it until the first account exists — whoever signs up first owns the workspace. Enter your email, set a strong password, and name your workspace.

Once you're in, do a quick smoke test to confirm the whole stack is actually wired together correctly:

1. Create a Company record and a Person attached to it — this exercises the core data model and confirms writes are landing in Postgres.
2. Open the Opportunities (or Deals) view and drag a card between pipeline stages — this is a good check that the UI and API round-trip cleanly.
3. Upload a file to a record (an avatar or an attachment) and reload the page — this confirms the worker and local file storage are both working, not just the server.

If all three work, the server, worker, Postgres, and Redis are all doing their job.

#Backups

Two things matter here, and losing either one hurts:

• The Postgres data — every contact, company, deal, and pipeline you've built lives in the db service's volume. This is the actual content of your CRM.
• .env — specifically ENCRYPTION_KEY. Restore a Postgres backup onto an instance running a different encryption key and anything Twenty encrypted at rest becomes unreadable, even though the raw rows are intact.

Dump the database and copy it, plus .env, off the box:

copydocker compose exec -T db pg_dump -U postgres default | gzip > twenty-db-$(date +%F).sql.gz

(Confirm the exact database/user names for your install with docker compose exec db env | grep PG_ if you changed anything from the .env.example defaults.) Also snapshot the storage volume that holds uploaded files and attachments — check docker compose config for the volume name if you're not sure which one it is.

Get all of it — the SQL dump, .env, and the storage volume — to an S3-compatible bucket or another machine on a schedule. A backup that only lives on the same server dies with the server, and an untested backup is a guess: periodically restore into a throwaway stack to confirm it actually works.

#Upgrades

Twenty ships new releases regularly. To upgrade, pull newer images and recreate the containers:

copydocker compose pull
docker compose up -d

The server runs pending database migrations automatically on boot, which is exactly why a fresh backup before you pull is non-negotiable — a migration changes your data in place and there's no undo without one. Read the release notes on the Twenty GitHub releases page before a major version bump, and consider pinning specific image tags in docker-compose.yml instead of riding latest, so you control exactly when you move and can reproduce the running version if something breaks.

#Troubleshooting

Server container restarts in a loop right after docker compose up -d. Usually it started before Postgres was ready to accept connections. Check docker compose logs db for startup errors first, then docker compose logs server — a docker compose up -d retry once Postgres settles is often enough.

The app loads but API calls fail, or links in the UI point at the wrong host. SERVER_URL doesn't match the address you're actually serving from. Set it to your real public HTTPS URL in .env and restart the stack — this is the same class of bug as a wrong WEBHOOK_URL in other self-hosted apps: the app has to know its own public address, it can't infer it from the request.

Uploaded files or avatars 404 after restarting the stack. The local storage volume isn't being persisted — confirm the compose file's storage volume mount survived any edits you made, and that you're not accidentally running with docker compose down -v, which deletes volumes.

Login sessions keep getting invalidated, or previously-working sessions break after a redeploy. ENCRYPTION_KEY changed between deploys. It must stay identical across restarts and upgrades — restore it from your backup if it drifted.

Certificate never issues / stuck on plain HTTP. This is a Caddy/DNS problem, not a Twenty one — confirm the A record for your domain has propagated (dig +short crm.example.com) and that port 80 is reachable from the internet for the ACME challenge to complete.

#Verification + next steps

You're done when you can: load Twenty over HTTPS on your own domain, sign in as the account you created, create and move records through a pipeline, upload a file and see it persist across a restart, and confirm a database dump plus .env are landing in off-box storage.

From here, invite your team, import existing contacts and companies, and build out the pipeline stages that match how you actually sell. The box underneath it is what makes or breaks the experience once real usage starts — 2 vCPU / 4 GB is the right tier to start. See Best VPS for CRM for the current options ranked by price.