Import an Existing Platform into Temps
Move an application from Coolify, Dokploy, CapRover, Easypanel, or another self-hosted platform without changing its Git history. You recreate the deployment configuration in Temps, verify the new deployment while the old platform remains live, and switch traffic only after the application and its data pass your checks.
What you're moving
Temps does not read another platform's database or configuration files directly. You move each application by mapping the source platform's settings to a Temps project:
| Existing platform setting | Temps destination |
|---|---|
| Git repository and branch | Project repository and production environment |
| Dockerfile or build preset | Project build configuration |
| Environment variables and secrets | Environment variables scoped to production, staging, or preview |
| Domains and TLS | Custom domains with automatic TLS |
| PostgreSQL, Redis, MongoDB, or S3 | Managed services or an external service |
| Persistent volumes | Project volumes |
| Scheduled tasks | Cron jobs |
| Health checks | Environment health-check settings |
Your repository, Dockerfile, and application code transfer unchanged. Platform-specific configuration—such as Coolify resource definitions, Dokploy Compose settings, or CapRover app definitions—does not transfer automatically because each platform models deployments differently.
If the source application uses Docker Compose, create one Temps project for the application container and move databases, caches, and object storage to managed services. Temps deploys one application container per project and does not execute a Compose file.
Migration checklist
Keep the existing platform online until the final DNS cutover. Before creating the Temps project, collect:
- Git repository URL, production branch, and app directory
- Dockerfile path or the current build, install, and start commands
- Container port and health-check path
- Environment variables for every environment
- Custom domains and current DNS records
- Database connection details and a current backup
- Persistent volume paths and an archive of their contents
- Cron schedules, commands, and required variables
- Webhooks or deploy hooks that call the old platform
Record secret values from their original password manager or configuration source. Platforms that mask stored secrets cannot export their values after creation.
Step 1: Inventory the current platform
Open each application in the source platform and write down the configuration before changing anything. Treat production, staging, and preview environments as separate inventories because they can use different branches, variables, domains, and service credentials.
Check the repository for platform-specific files:
| File or setting | Migration action |
|---|---|
Dockerfile | Keep it. Temps detects and builds it directly. |
docker-compose.yml or compose.yaml | Split the app container from databases and other stateful services. |
| Nixpacks configuration | Keep it and select the matching build preset. |
| Platform deploy hooks | Replace them with Git push deployment or a Temps webhook. |
| Platform-generated domains | Replace them with a Temps preview URL during verification. |
| Source-platform environment variables | Remove them unless the application reads them directly. |
For every variable that contains a hostname or URL, mark whether it points to the old platform. Database URLs, Redis URLs, storage endpoints, callback URLs, CORS origins, and public application URLs must point to the new service before cutover.
Step 2: Prepare data and storage
Create backups while the source application is healthy, then test that you can read them before starting the cutover.
For PostgreSQL, Redis, MongoDB, and S3-compatible storage, create the corresponding Temps service and follow the service-specific migration path:
Restore databases into the new service before changing the application's connection variables. For a write-heavy application, take an initial backup for rehearsal, then schedule a short write freeze and take a final backup immediately before DNS cutover.
Archive each persistent volume from the source host and copy it to the new server. Mount the destination volume at the same container path so the application does not need a code change. Verify file ownership and permissions from inside the deployed container before accepting traffic.
Step 3: Create the Temps project
Create the replacement project
- 1
In the Temps dashboard, go to Projects and click New Project.
- 2
Connect the same Git repository and branch used by the existing platform.
- 3
Copy the build preset, app directory, Dockerfile path, port, and health-check path from your inventory.
- 4
Add the production environment variables and connect the replacement managed services.
Checkpoint: Confirm the project summary shows the expected repository, branch, build method, and production environment before deploying.
Add variables under Project → Environment Variables and scope each value to the correct environment. See Manage environment variables for dashboard and CLI instructions.
Create project volumes at the same container paths used by the source application. Recreate scheduled work under Cron Jobs, then replace any webhook or CI destination that still points to the old platform.
Deploy the project without changing production DNS. Temps provides a URL you can use to test the replacement deployment while the source platform continues serving traffic.
Step 4: Verify and cut over
Test the new URL with the same checks you use in production:
- Load public pages and authenticated pages
- Submit forms and complete authentication callbacks
- Read and write representative database records
- Upload and retrieve a file from persistent or object storage
- Trigger a background job and a cron command
- Confirm health checks, logs, analytics, and error tracking receive data
Fix every failing check before changing DNS. Lower the domain's DNS TTL before the maintenance window, pause writes if the final data restore requires it, take the final backup, restore it, and run the verification list again.
Move the production domain
- 1
Open the project, go to Settings, then Domains, and click Add Domain.
- 2
Enter app.yourdomain.com and copy the DNS record shown by Temps.
- 3
Update the record at your DNS provider without deleting the application on the old platform.
Checkpoint: Confirm the domain resolves to the Temps server, TLS is active, and the production verification checks still pass.
If verification fails after cutover, restore the previous DNS record. The source application remains your rollback target until you deliberately remove it.
After migration
Keep the source platform and its backups available until DNS caches have expired and you have observed normal production traffic, scheduled jobs, and data writes on Temps.
Then:
- Create a fresh backup from the Temps-managed database and verify its restore path.
- Configure backups and monitoring.
- Remove deploy hooks and credentials that belonged to the old platform.
- Revoke old API tokens and rotate any secret that passed through an export file.
- Delete the old application only after the rollback window closes.
For platform-specific details, use the dedicated guides for Vercel, Netlify, Heroku, Railway, Render, and Fly.io.