Bring a VitoDeploy instance over as drafts, then adopt the real servers.
VitoDeploy is self-hosted, so SrvYard asks for its address as well as an API token. It reads projects, servers and sites through Vito’s API and shows a plan you review. Your Vito is never written to, and no server is changed.
# your own instance
address https://vito.example.com (https required)
token Vito, Settings, API keys
scope read; .env values need a read and write token
checked GET /health, then your projects and servers
scripts shown beside their translation, never run
vito untouched01What you need
02How it goes
import, then scan, then adoptImport
Open Import / migrate, choose VitoDeploy, paste the read-only token and press Verify and continue. One read call checks it.
Pick servers
Tick the servers to read. Each site costs several calls to the other panel’s API, so a big account takes a few minutes. Reading
.envfiles is a separate switch, off by default.Review the plan
Totals of new drafts, updates and skipped items, then a card per server with a tick box for every site, daemon, scheduled job, database and firewall rule. Deploy scripts appear beside their translation.
Create the drafts
Tick that you read the deploy scripts, choose whether to delete the token (recommended) and press Create drafts. Nothing is installed.
Connect, scan, adopt
Connect the real server, scan it, and adopt what the scan found. Deploy once from SrvYard, check domains and certificates, and only then change DNS.
03The import screen
from the demo organisation
04What the import reads and what it creates
all of it read-only| Read from VitoDeploy | Becomes in SrvYard |
|---|---|
| Projects and their servers | Custom servers that await access (the picker shows project and server) |
| Services of each server | Noted for the review |
| Sites, domains, repository | Sites marked Needs provisioning |
| Deployment script of each site | A draft script, translated, with a verdict per line |
| Workers | Daemons |
| Cron jobs | Scheduled jobs |
| Databases and database users | Database records (no passwords) |
| Firewall rules and SSH keys | Firewall rules and key names |
| Redirects | Redirects |
The .env of each site, if you asked | Key names, and values only if you tick them per site |
Drafts, not machines
Servers become custom servers awaiting access, sites say Needs provisioning, and daemons, scheduled jobs, databases and firewall rules are records that are applied once the server is connected. Every item is tagged with the panel’s name. Nothing touches a machine and nothing is written to VitoDeploy.
Deploy scripts
Each line is shown with a verdict: unchanged, translated (a variable renamed, or a step SrvYard does itself removed), review (an old absolute path, a variable SrvYard does not have) or unsupported (commented out: anything that needs sudo, or restarts Supervisor). The script is never run by the import; it runs only at a deployment you start.
05What is never copied
because the API will not give it to you- Database user passwords, SSH private keys, storage and source control tokens: the API does not return them.
- Site aliases and redirect-only domains: Vito does not expose them through its API.
- Custom certificates and their keys.
- A load balancer site has no SrvYard equivalent and comes in as a plain site to adapt by hand. A Node.js site comes in as type Other, and its start command stays a daemon in Vito.
Environment files are read only if you switch it on, and imported only for the sites you tick; without that, key names alone can be shown. The token and everything read with it are encrypted, expire after an hour and are deleted when you finish or cancel. Delete the token in VitoDeploy too.
How your data is handled during an import is also spelled out on the security page.
06Then scan and adopt the real server
the half that reads the machineVito installs an agent and a vito user and leaves /etc/vito-agent and /var/lib/vito. The scan recognises these marks, so the report can adopt a Vito site in place.
The scan is read-only. You choose what it may read, and every consent lists its exact commands. Private keys, database passwords and password hashes are never read. Adopting registers each site where it already is, in observe mode: SrvYard writes nothing to the web server, keeps a restore point, and can roll back.
The Vito importer was exercised against a real VitoDeploy 4.1.1 during development; other versions may differ in what the API returns, in which case the review lists what could not be read.
07Switching the old panel off
a guide, never run for youThe guide has you stop and remove the Vito agent (a systemd service), remove Vito’s SSH key from every authorized_keys that has it, and decide about the passwordless sudo line for the vito user. Two things to plan for: a wildcard certificate renewed through manual DNS hooks calls back to your Vito and stops renewing, so re-issue it through SrvYard’s DNS integration; and git webhooks created by Vito still call your Vito, so create SrvYard’s push-to-deploy webhook and delete the old one. Keep Nginx’s user vito; line until you convert it on purpose.
SrvYard shows a detach guide per panel after adoption. Every command in it is for you to read and run; SrvYard never executes it. Keep the old panel running a few days as a safety net, then cancel it.
Adoption in depth: Adopt a site that is already on your server.
08Questions
answers from the docsWhy does my Vito address get refused?
It must start with https:// and be reachable from SrvYard. Addresses on private networks are refused unless the SrvYard instance has been set to allow them.
Why were my `.env` values not read from Vito?
Vito shows real environment values only to a token that can also write. Use a read and write token, or paste the values yourself. Everything else imports with a read token.
Import one Vito site. Keep Vito running until it works.
Free: 1 server, 3 sites, 100 deploys a month. Read the docs first if you prefer.