Documentation

From a fresh VPS
to an operated stack.

Start on a supported server you can recover through your hosting provider's console. Read the scripts before granting administrative access.

Requirements

Ubuntu 24.04 LTS on x86_64, an administrator account with a working SSH key, Docker Engine with the Compose plugin, and a domain pointing to your server. Only SSH and the reverse proxy's HTTP/HTTPS ports should be reachable publicly.

Resources are checked against the selected stack manifest. Supabase needs at least 4 GB RAM, 2 CPU cores, and 40 GB storage on its own; plan additional capacity for other workloads. The five stacks do not all fit on a minimal VPS.

Install the kit

Use the licensed ZIP from Polar, or inspect the public bootstrap before running it. The bootstrap requests your license securely and verifies the downloaded archive's checksum.

curl -fsSL https://deploykit.dev/install | bash

For automated use, supply the license in a protected file using the installer's --license-file option. Do not paste secrets into command history, logs, or support messages.

deploykit --help
deploykit doctor
deploykit init --help

The installed kit lives under /opt/deploykit. Configuration is separated under /etc/deploykit, application projects under /srv/deploykit, and runtime state under /var/lib/deploykit.

Deploy a stack

Start with proxy-core for TLS and routing. Then choose WordPress, n8n, Supabase, or monitoring. Inspect the generated configuration and the stack's included README before deployment.

deploykit init --apply
deploykit stack deploy proxy-core --name proxy
deploykit stack deploy wp-high-perf --name blog --domain blog.example.com
deploykit stack status blog

The CLI supports --dry-run and configuration files. Database and Redis services stay on private networks. Existing project files are preserved during kit updates; stack upgrades are a separate operation.

Harden SSH carefully

Verify your administrator key and keep a second working session open. SSH configuration is validated before reload. A port change requires an explicit request and a successful confirmation before its timed rollback is cancelled. Keep provider-console access available.

deploykit harden --help

Swap and system tuning are explicit operations. They are not silently applied while installing a stack.

Back up, then prove recovery

Configure a private S3-compatible bucket and a protected restic password. Backups include consistent database dumps, persistent application files, and configuration needed for recovery.

deploykit backup configure --help
deploykit backup run --help
deploykit backup restore --help

The default retention is 7 daily, 4 weekly, and 6 monthly snapshots. Restore to a fresh destination first, start the application, and verify its data before changing traffic. A successful upload is not proof that a backup can be restored.

Licenses and updates

Starter licenses include 1.x kit releases. Pro licenses allow new releases while the subscription benefit remains valid. License validation controls distribution and updates, not the operation of installed containers or scheduled backups.

deploykit update --help
deploykit stack upgrade --help

Review release notes and take a fresh backup before upgrading a stack. Database major-version migrations require a deliberate migration procedure.

Optional sandbox telemetry

The agent sends CPU, memory, and disk measurements every five minutes. It is disabled until you enable it. Enrollment and billing events are restricted to Polar sandbox in this release.

deploykit telemetry enable --help
deploykit telemetry status
deploykit telemetry disable

Each queued measurement keeps its event ID across retries. The queue is bounded to 24 hours. Disabling telemetry revokes the agent token and removes its schedule.

Troubleshooting

The downloaded kit contains detailed per-stack instructions and recovery procedures.