Migrate from Dokku to Temps

To move a Dokku app to Temps: deploy the same Git repository (Temps auto-detects the runtime, or uses your Dockerfile), export the app's config with dokku config:export, restore a dokku postgres:export dump into a Temps managed PostgreSQL service, move storage mounts to S3 or a Compose volume, then cut DNS over. Both platforms build from Git and run your app in Docker containers, so most apps move without code changes. The import wizard doesn't discover Dokku apps, so this is a manual migration.

For how the two platforms differ beyond migration, see Temps vs Dokku.


Builds and the Procfile

Dokku builds an app with Heroku-style buildpacks (Herokuish), Cloud Native Buildpacks or a Dockerfile. Check which one your app uses:

dokku builder:report your-app

On Temps:

  • Dockerfile apps deploy unchanged. Temps treats any repository with a Dockerfile as a Docker project.
  • Buildpack apps are rebuilt from the files in the repository. Next.js, Vite, Python, Go, Rust, Java and more are detected automatically; a plain Node.js server (Express, NestJS) uses the Node preset you pick, Rails apps the nixpacks-ruby preset and Laravel the nixpacks-php preset (see supported platforms). There are no custom buildpacks: if you rely on one, add a Dockerfile instead.

Temps picks the container port from the project's port setting, then the image's EXPOSE, then 3000 (see Ports), and sets PORT for your app. Bind to process.env.PORT with a fallback rather than a port hard-coded for Dokku:

const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0");

Procfile processes

Autopack builds use the web: line of a Procfile as the start command. Other process types are not run:

  • Workers (worker: lines you scaled with dokku ps:scale): Temps has no worker process type, and a project that doesn't answer HTTP fails its health check. Deploy the app as a Docker Compose project with a web service and a worker service; services that don't publish a port stay off the proxy.
  • release: and app.json deploy tasks (scripts.dokku.predeploy and postdeploy): Temps has no release phase or pre-deploy command and doesn't run migrations for you. Run them as a one-off step after the deploy, as described in Release phase and migrations.

Environment Variables

Export the app's variables on the Dokku server as a dotenv file:

dokku config:export --format envfile your-app > your-app.env

Remove the variables that won't apply on Temps before importing:

Dokku variableAction
DATABASE_URL (set by postgres:link)Map to the POSTGRES_URL Temps injects when you link a managed database (see below)
REDIS_URL (set by redis:link)Remove: linking a Temps managed Redis injects its own REDIS_URL
DOKKU_*Remove: these configure Dokku itself
PORTRemove: Temps sets it to the project's port

Then import the file with bunx @temps-sdk/cli environments vars import your-app.env -p my-app -e production, or add the variables in Temps → Project → Settings → Environment Variables.


Postgres Migration

Export data

The dokku-postgres plugin exports a database in PostgreSQL's binary custom format, which pg_restore reads:

dokku postgres:export your-db > your-db.dump

Temps doesn't create a database for you on deploy: create a PostgreSQL service, then link it to the project. Linking creates a database named <project>_<environment> and injects POSTGRES_URL, POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD into that environment.

bunx @temps-sdk/cli services create -t postgres -n my-app-db -y
bunx @temps-sdk/cli services list                    # note the service ID
bunx @temps-sdk/cli services link --id <service-id> -p my-app
bunx @temps-sdk/cli services env --id <service-id> -p my-app  # POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB

Restore to your new database

The managed database isn't reachable from the internet: on the Temps server it listens on 127.0.0.1, on a host port assigned from 5432 (docker ps on the server shows it). Copy the dump to the Temps server and restore it into the linked database, using the user, password and database name from services env:

scp your-db.dump user@your-temps-server:/tmp/
ssh user@your-temps-server
pg_restore --verbose --no-acl --no-owner \
  -d "postgresql://<POSTGRES_USER>:<POSTGRES_PASSWORD>@127.0.0.1:<host-port>/<POSTGRES_DB>" \
  /tmp/your-db.dump

Test the restore against a scratch database first and check that row counts match before pointing your app at the new database.

Point the app at it

Your code probably reads DATABASE_URL. Either change it to read POSTGRES_URL, or set DATABASE_URL to the same value as POSTGRES_URL in the environment's variables (copy it from bunx @temps-sdk/cli services env --id <service-id> -p my-app). Then run your migrations once.


Redis and Other Plugins

Dokku pluginTemps replacement
dokku-postgresManaged PostgreSQL, as above
dokku-redisManaged Redis; link it and it injects REDIS_URL
dokku-mariadb / dokku-mysqlManaged MariaDB (MySQL wire-compatible)
dokku-mongoManaged MongoDB
dokku-letsencryptBuilt in: Temps issues and renews Let's Encrypt certificates for every domain
Cron tasks in app.jsonCron jobs: .temps.yaml entries that call an HTTP path on a schedule, so a scheduled command becomes an endpoint

Create each replacement as a managed service and link it to the project. Check any other plugin you rely on before you migrate: Temps has no plugin system for Dokku plugins.


Persistent Storage

Dokku apps keep files on the host through bind mounts, usually under /var/lib/dokku/data/storage. List them with:

dokku storage:list your-app

Temps app containers have no persistent volumes, so move that data before you switch:

  • Uploads and other files your app writes: store them in S3-compatible storage, either a managed S3 service on the same server or an external bucket, and copy the existing files into it.
  • Data that must stay on local disk: deploy the app as a Docker Compose project with a named volume.

Deploy

# Install Temps if not already done
curl -fsSL https://temps.sh/deploy.sh -o deploy.sh
less deploy.sh
bash deploy.sh
  1. Go to Projects → New Project in the Temps console
  2. Connect your Git repository (the same one you git push to Dokku)
  3. Add environment variables
  4. If using a Dockerfile, Temps detects it automatically; otherwise choose the preset and, if needed, set your build and start commands
  5. Click Deploy

Custom Domains

List the app's domains on Dokku:

dokku domains:report your-app

On Temps:

  1. Go to Project → Settings → Domains → Add Domain (or run bunx @temps-sdk/cli custom-domains create --project-id <id> -d app.example.com -y)
  2. Add the DNS records shown (A or CNAME)
  3. Temps provisions TLS automatically via Let's Encrypt

Verify and Cut Over

  1. Test your app at its Temps URL end-to-end (auth, database reads and writes, file uploads, background jobs)
  2. Stop writes on Dokku, take a final postgres:export and restore it, then cut DNS over to Temps
  3. Keep the Dokku app and its data for a few days as a fallback, then remove the domain with dokku domains:remove your-app app.example.com

Next Steps

Last updated

Was this page helpful?