Your own VM and server

A handy setup: the project runs and is checked on the platform or your own VM — that’s staging — while production lives on your server through Panel Prod. Production logs, database and users stay with you; builds, deploys, domains and certificates run from the same dashboard.

Environments — one project in several places

• In the project settings, block “Where the project runs” → “Create a copy” on your own server or your own VM, with an empty database or with data. An instance of the project, <name>-prod (or -vm), appears in the same team.
• An environment has its own variables (the address is replaced with the new one), its own database — empty or a copy of the data at creation time — its own Redis and its own domains.
• In the project, environments are tabs above the title: “prod”, “preprod” or your own label (changed in settings); without a label — the place: “Platform”, “VM · vm3”.
• “Deploy here” builds in the environment the same commit that runs in the other one: checked on staging — shipped to production. The build uses production’s variables, so NEXT_PUBLIC_* and other build-time values are each environment’s own.
• Autodeploy is off for an environment: production updates only through deploys from another environment. The main project keeps its autodeploy setting.
• The main project can be deleted after its environments; deleting an environment leaves the main project untouched.

Moving without downtime: your domains on the copy right away

• In “Where the project runs”, the copy has a “Domains «…» → here” button: the main server forwards requests for the main project's custom domains to the copy while A records still point to it. The site runs in the copy with its database right away.
• Data written to the main project's database after the copy was created does not reach the copy — switch right after creating it or create the copy again.
• Variables of the copy with the site address (APP_URL, AUTH_URL, NEXT_PUBLIC_SITE_URL) must be your domain, not the copy's tech address — otherwise OAuth sign-in and links lead to the tech address. The panel lists the ones that still point there.
• Your domains are added to the copy right away, waiting for DNS: change the A records to the new server's IP and the domain connects there by itself (checked every 5 minutes), leaves the old project, and so does the forwarding.
• You can stop the old project right after switching; delete it after the DNS change (deleting removes the forwarding). While forwarding is on, requests pass through the platform's main server.

Or move it as a whole

• Move a project to production as a whole — in the project settings, block “Where the project runs” → “Move”.
• Move your whole VM to production — VM page → Panel Prod → “Move the whole VM”: all projects at once, databases are copied.
• If any build fails during the move, everything returns to where it was — sites are never left without a version.

What to choose when

• Fast response and near-100% uptime are critical, with or without VPN: a VDS for your project or team (from 300 ₽/month) or your own server via Panel Prod — a direct route with no intermediaries, resources only yours.
• You just need isolation: your own VM “+ Admin” — your own cores and memory on our servers; requests to the VM take an extra routing step through the platform entry.
• Many projects, spiky load, databases, Redis and storage, no strict response requirements: stay on the platform — powerful servers (200 GB of memory, 104 threads, NVMe) absorb spikes, everything is already set up.

How a request travels

• Platform: the main server’s Traefik, certificates are issued automatically.
• Own VM: platform entry → Traefik on the VM. A custom domain is an A record to the entry address.
• Own server: the A record points straight to the server, Traefik runs on it.
• During a move: the main server forwards the domain’s requests to the copy — an instant switch and one-click rollback at the cost of one extra hop.

Why move

• A separate production: production with user data on your own server, development and previews on the platform.
• Your own resources, no plan limits: as many cores and as much memory as the server has.
• Your data stays with you: the production database and logs live on your server; builds, deploys and management stay on the platform.
• Your load is yours: bots and traffic spikes of one site do not affect other projects.

How to move

• 1. Connect a server (VM page → Panel Prod) or order your own VM.
• 2. In project settings, “Where the project runs” → “Create a copy” on the new host, database “with data”. The copy is built alongside while the old site keeps running.
• 3. Check the copy at its tech address. In its variables set the site address (APP_URL, AUTH_URL, NEXT_PUBLIC_SITE_URL) to your domain.
• 4. On the copy press “Domains «…» → here” — from that moment your domain opens the copy.
• 5. Stop the old project and turn on auto-deploy for the copy so pushes build it.
• 6. Change the domain’s A records to the new server’s IP — nothing else to do: the domain is already waiting on the copy and connects by itself (checked every 5 minutes), leaving the old project, and the forwarding goes away too.

Why there is no downtime

• The copy comes up alongside while the old site runs: build, database and checks happen before the switch.
• The switch happens on the platform side: the main server starts forwarding your domain’s requests to the copy. No waiting for DNS — all visitors switch at once.
• Changing the A record later is invisible: visitors still on the old IP reach the copy through the platform, those on the new IP reach it directly. Both paths lead to the same app and database.
• The certificate on the new server is issued once DNS points to it — until then the domain works with its current certificate through the platform.
• Rollback is the “Return domains” button: requests go to the old project again.

Keep in mind

• Data written to the old database after the copy was created does not reach the copy — switch right after checking or create the copy again.
• Background jobs (mailings, updates, bots) would run in two places — stop the old project after the switch.
• While forwarding is on, requests pass through the main server; after the DNS change — directly.
• Don’t want to deal with a server — a VDS for your project from 300 ₽/month: write to support, we rent and set up the server, move the project and database and switch the domains. Logs and backups as you decide.