Move your app. Bring its data.

Connect your repository, review the requirements strackt detects, and add an empty server to the app. strackt sets up the system, connects the services and deploys your code. Keep your existing app running where it is while you prepare the new setup.

Server setup replaces the operating system and erases its contents. Use a fresh server, rather than the server currently running your app. You can make the move yourself; contacting support is optional. See Connect a server for the setup steps.

Code comes from your repository. strackt deploys releases from it, so changes you need to keep belong in the repository.

Uploads and other writable files belong in persistent paths. These survive new releases. Check the app’s persistent-path settings before transferring files; copying uploads only into a disposable release directory will not preserve them across deploys.

The database is a connected service. Import your existing data into the database connected to the new environment. Keep the app’s secrets and external services in mind too: its encryption key, mail, object storage and payment callbacks may need the same settings as before.

You have full server login access over SSH. With SSH access enabled for your workspace, use SFTP, rsync or your preferred SSH-based tool to copy uploads and other persistent files. Set up your client with your strackt SSH credentials; a personal key alone is not the signed login. The SSH guide covers enabling access and opening a shell with the strackt CLI.

Copy into the persistent paths for the new app and check that the app can read and write them. Test an existing upload and create a new one before switching traffic.

Open the database service and choose Connect. The dialog supplies an SSH tunnel command and a temporary connection URL for your database client, including MySQL-compatible clients for MariaDB. The strackt CLI and workspace SSH access must be ready first.

Run the tunnel command and leave it open while you work. Confirm the database name before importing your export: when a service is shared, check that the session targets the app you are moving. Use a compatible database export, rather than copying a running database’s raw files. If the temporary login expires, open Connect again. The database connection guide walks through the dialog and connection details.

Check the new app before changing DNS: pages, login, existing uploads, database reads and writes, and any jobs or integrations it runs. Keep scheduled jobs and outgoing notifications from running twice while both copies exist.

For an app that is still accepting writes, plan a final sync: pause writes on the old app, transfer the remaining files and database changes, check the new copy, then switch your domain. Keep the old hosting until the move is verified. Returning DNS to the old host does not bring back data written only to the new database.

Want a second pair of eyes? Email Jan Peter (JP) or use the chat on this page. JP can help you work through the setup or a move that needs extra care.

Back to how switching works · Server access and permissions.