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
Dockerfileas 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-rubypreset and Laravel thenixpacks-phppreset (see supported platforms). There are no custom buildpacks: if you rely on one, add aDockerfileinstead.
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 withdokku 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 awebservice and aworkerservice; services that don't publish a port stay off the proxy. release:andapp.jsondeploy tasks (scripts.dokku.predeployandpostdeploy): 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 variable | Action |
|---|---|
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 |
PORT | Remove: 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
Create and link the Temps database
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 plugin | Temps replacement |
|---|---|
dokku-postgres | Managed PostgreSQL, as above |
dokku-redis | Managed Redis; link it and it injects REDIS_URL |
dokku-mariadb / dokku-mysql | Managed MariaDB (MySQL wire-compatible) |
dokku-mongo | Managed MongoDB |
dokku-letsencrypt | Built in: Temps issues and renews Let's Encrypt certificates for every domain |
Cron tasks in app.json | Cron 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
- Go to Projects → New Project in the Temps console
- Connect your Git repository (the same one you
git pushto Dokku) - Add environment variables
- If using a Dockerfile, Temps detects it automatically; otherwise choose the preset and, if needed, set your build and start commands
- Click Deploy
Custom Domains
List the app's domains on Dokku:
dokku domains:report your-app
On Temps:
- Go to Project → Settings → Domains → Add Domain (or run
bunx @temps-sdk/cli custom-domains create --project-id <id> -d app.example.com -y) - Add the DNS records shown (A or CNAME)
- Temps provisions TLS automatically via Let's Encrypt
Verify and Cut Over
- Test your app at its Temps URL end-to-end (auth, database reads and writes, file uploads, background jobs)
- Stop writes on Dokku, take a final
postgres:exportand restore it, then cut DNS over to Temps - 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