How to Deploy Infisical on a VPS

copysudo apt-get update && sudo apt-get -y upgrade
sudo apt-get install -y curl openssl ufw dnsutils

copyadduser deploy
usermod -aG sudo deploy

copysudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable

#Install Docker

If Docker isn't on the server yet, the convenience script installs Docker Engine and the Compose plugin (the Docker and Compose on Ubuntu guide covers the details):

copycommand -v docker >/dev/null || curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
sudo docker compose version

The group change applies on your next login; until then the commands below use sudo docker.

#Install Infisical

Infisical publishes a template .env file with sample secrets in it. The sample secrets are public, so they must be replaced before the first start. This block downloads the template from the same release as the image you are about to run, swaps in fresh random values, and sets the site address. Set your hostname first (this guide uses secrets.example.com; replace it with yours). The guard keeps the step safe to re-run: regenerating the encryption key on an existing install would make everything already stored unreadable.

copymkdir -p ~/infisical && cd ~/infisical
DOMAIN=secrets.example.com
if [ ! -f .env ]; then
  curl -fsSL -o .env https://raw.githubusercontent.com/Infisical/infisical/v0.166.3/.env.example
  sed -i "s|^ENCRYPTION_KEY=.*|ENCRYPTION_KEY=$(openssl rand -hex 16)|; s|^AUTH_SECRET=.*|AUTH_SECRET=$(openssl rand -base64 32)|; s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -hex 16)|; s|^SITE_URL=.*|SITE_URL=https://$DOMAIN|" .env
  echo "DOMAIN=$DOMAIN" >> .env
  chmod 600 .env
fi
grep -c -E '^(ENCRYPTION_KEY|AUTH_SECRET|POSTGRES_PASSWORD|SITE_URL)=' .env

The ENCRYPTION_KEY in that file encrypts everything Infisical stores. If you lose it, the database is unreadable, and no backup of the database alone will save you. Copy .env to your password manager or offline storage now.

Now the Compose file. It is based on Infisical's own production example, with four changes: the image tag is pinned (the upstream file runs latest and its own comment says to pin it), the app binds to loopback, Caddy is added in front, and Redis gets a named volume. The app and the database read the same .env:

copycd ~/infisical
cat > docker-compose.yml <<'EOF'
services:
  backend:
    image: infisical/infisical:v0.166.3
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
    env_file: .env
    environment:
      NODE_ENV: production
    ports: ["127.0.0.1:8080:8080"]
  redis:
    image: redis:7-alpine
    restart: always
    volumes: ["redis_data:/data"]
  db:
    image: postgres:17-alpine
    restart: always
    env_file: .env
    volumes: ["pg_data:/var/lib/postgresql/data"]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 10s
      retries: 10
  caddy:
    image: caddy:2
    restart: always
    ports: ["80:80", "443:443"]
    environment:
      DOMAIN: ${DOMAIN}
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro", "caddy_data:/data"]
    depends_on: [backend]
volumes:
  pg_data:
  redis_data:
  caddy_data:
EOF
cat > Caddyfile <<'EOF'
{$DOMAIN} {
    encode zstd gzip
    reverse_proxy backend:8080
}
EOF

Start it and wait for Infisical to answer. The first boot runs database migrations, so the loop below is bounded rather than open-ended:

copycd ~/infisical
sudo docker compose up -d
code=000
for i in $(seq 1 60); do
  code=$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/api/status)
  [ "$code" = "200" ] && break
  sleep 3
done
echo "Infisical answered HTTP $code"
sudo docker compose ps

HTTP 200 and the db container healthy means the stack works. If it never answers, jump to Troubleshooting.

#HTTPS + domain

Create an A record for your hostname (say secrets.example.com) pointing at the server's public IP, and confirm it resolves before Caddy tries to get a certificate:

copydig +short secrets.example.com

Caddy is already running. It requests the certificate as soon as the name resolves and renews it on its own (see Automatic HTTPS with Caddy for how that works). Check that HTTPS answers, retrying while the certificate is issued:

copy. ~/infisical/.env
for i in $(seq 1 20); do
  out=$(curl -s -o /dev/null -w '%{http_code} %{ssl_verify_result}' "https://$DOMAIN/api/status") && [ "${out%% *}" = "200" ] && break
  sleep 5
done
echo "HTTPS status and certificate check: $out"

A second number of 0 means the certificate verified. Do this before creating the admin account, so the dashboard, invitation links and the CLI all use the https address from the start.

#First login and hardening

Infisical has no default account. The first person to open the admin signup page becomes the instance administrator, so do it right after HTTPS works, before anyone else finds the address. Open https://secrets.example.com/admin/signup, enter your email and a long random password, and store it in your password manager. The instance reports whether that has happened yet:

copy. ~/infisical/.env
curl -s "https://$DOMAIN/api/v1/admin/config" | grep -o '"initialized":[a-z]*'

"initialized":false means nobody has claimed the instance; after you sign up it reads true. Creating the administrator itself was not tested in this guide's verification run, since it happens in the browser.

Then:

1. In the Admin Console (the server administration area, not an organization), turn open signups off once your team has joined, or restrict them to your email domain. An open signup page on a secrets manager is an invitation.
2. Create an organization and invite teammates by email, and use the machine-identity feature for applications rather than a personal login.
3. Turn on two-factor authentication for every human account.
4. Configure SMTP (the SMTP_* lines in .env, then sudo docker compose up -d) so invitations and password-reset emails reach people. Without it you have to hand out invitation links yourself. SMTP delivery was not tested in this guide's verification run, because it needs a live provider account.

#Backups

Two things must survive: the PostgreSQL database and the .env file that holds the ENCRYPTION_KEY. A database backup without the key is unreadable, and the key without the database is worthless, so keep the pair together. Redis holds queues and caches rather than your secrets, so this guide does not back it up. Start with a database dump:

copycd ~/infisical
sudo docker compose exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  > ~/infisical-db-$(date +%F).sql
chmod 600 ~/infisical-db-$(date +%F).sql
test -s ~/infisical-db-$(date +%F).sql && ls -lh ~/infisical-db-*.sql

Then archive the configuration. This archive contains the encryption key and the database password, so the command restricts it to its owner:

copycd ~/infisical
sudo tar czf ~/infisical-config-$(date +%F).tar.gz docker-compose.yml Caddyfile .env
sudo chmod 600 ~/infisical-config-*.tar.gz
ls -lh ~/infisical-config-*.tar.gz

Copy these files off the server, to encrypted object storage or another machine, and run the pair from cron. Because they hold the key to your secrets, treat the destination with the same care as the server itself. A backup you have never restored is a guess, so prove the dump loads. This starts a throwaway PostgreSQL container, imports the dump and counts the tables it created:

copycd ~
sudo docker rm -f infisical-restore-test >/dev/null 2>&1
sudo docker run -d --name infisical-restore-test -e POSTGRES_PASSWORD=scratch postgres:17-alpine >/dev/null
for i in $(seq 1 40); do
  sudo docker exec infisical-restore-test pg_isready -h 127.0.0.1 -U postgres >/dev/null 2>&1 && break
  sleep 2
done
sudo docker exec infisical-restore-test createdb -U postgres infisical
sudo docker exec -i infisical-restore-test psql -q -U postgres -d infisical < ~/infisical-db-$(date +%F).sql >/dev/null
sudo docker exec infisical-restore-test psql -U postgres -d infisical -At \
  -c "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'public'"
sudo docker rm -f infisical-restore-test >/dev/null

It should print the number of tables, a number well above zero (it printed 769 in this guide's verification run). The check proves the dump loads and the schema is intact; it does not decrypt any secret, since that needs the key from your config archive. For a real restore onto a new server, install Docker, unpack the config archive into ~/infisical, start only the database (sudo docker compose up -d db), pipe the dump into it with sudo docker compose exec -T db sh -c 'psql -U "$POSTGRES_USER" "$POSTGRES_DB"', then start everything.

#Upgrades

Because the image tag is pinned, an upgrade is an edit. Check Infisical's release notes, take a backup (previous section), change the tag in docker-compose.yml, then pull and recreate:

copycd ~/infisical
sudo docker compose pull
sudo docker compose up -d
sudo docker compose logs --tail 20 backend

Infisical runs its database migrations automatically on the first start of a new version, and those are one-way, which is why the backup comes first. Releases are frequent, so move on a schedule you control rather than on every tag, and read the notes for anything that mentions migrations or configuration. Keep the postgres major version pinned too; a new PostgreSQL major is a dump-and-restore job, not a tag bump.

#Troubleshooting

The dashboard returns 502 through Caddy, or never answers. Check sudo docker compose ps: if backend is restarting, read sudo docker compose logs backend. The usual cause is a database connection error, which happens when .env was regenerated after the database volume already existed with the old password. Restore the original .env, or remove the volumes if the install holds no data yet.

Everything is stored but unreadable after a restore. The ENCRYPTION_KEY differs from the one used when the data was written. There is no workaround; restore the original .env.

Caddy never gets a certificate. Confirm dig +short secrets.example.com returns the server's IP and that your provider's network-level firewall, not just ufw, allows inbound 80 and 443. A blocked port 80 silently breaks the ACME challenge.

The backend is killed or restarts under load. Run sudo docker stats and dmesg | grep -i oom. An out-of-memory kill means the server is too small for the stack; move up a tier rather than adding swap to a secrets service.

Invitations and password resets never arrive. SMTP is not configured or the provider rejects the sender. Fill in the SMTP_* lines and check sudo docker compose logs backend for delivery errors.

#Verification + next steps

You're done when https://secrets.example.com loads with a valid certificate, you can sign in as the administrator, docker compose ps shows every service up after a reboot (restart policies bring them back), and you have restored a backup, with the key, onto a scratch box at least once.

From there, create a project and environments, add your first secrets, install the Infisical CLI on a workstation and point it at your own address, and wire a machine identity into one deploy pipeline. See the Infisical entry for catalog details and Best VPS for self-hosting for the ranked server picks.