Import from Railway, Render or Vercel

If your app already runs on Railway, Render or Vercel, you do not have to describe it to Cloady from scratch. Point Cloady at the provider once and it reads the service back — repository, branch, environment variables, disk size, port, custom domains — and pre-fills the New application card with what it found.

Import never creates anything on its own. It fills in the form; you review it and press deploy.

One service, one application

Cloady imports one provider service at a time, and each becomes one Cloady application.

A project with a web service, a worker and a database is therefore three imports and three applications. That is deliberate: it matches how Cloady deploys, and it keeps each piece independently scalable and restartable.

One consequence worth planning for. If your services referenced each other through provider-generated variables, those references come across as the value they had at the time, with a warning. After the last import, open each app's Variables and repoint them at the sibling's Cloady address.

Before you start

You need an access token for the provider. It is used for that single import, is never written to your account, and never appears in logs.

Prefer the narrowest token the provider offers, and revoke it afterwards. Cloady only ever reads.

Run the import

1. Open your workspace and click Import, in the header beside Invite, Billing and Settings. On a narrow screen it sits in the tools menu.
2. Pick Railway, Render or Vercel.
3. Paste the token. Optionally narrow the listing with a scope — a Railway workspace, a Render owner id (usr- or tea-), or a Vercel team.
4. Cloady lists what it can import, grouped by project. Anything it cannot take is listed too, with the reason.
5. Choose a service. The New application card opens already filled in.
6. Review it — especially variables — and deploy.

Deploy it within the hour. A picked service is staged temporarily and is cleaned up after an hour if you never deploy it; if that happens, just pick it again.

What comes across

Railway

Its image or GitHub repository, variables, volume size and mount path, port, replicas and verified custom domains. For repository services, the build and start commands and the root directory come too.

Not imported. Sealed variables — Railway never returns them, so they are listed for re-entry. Cron schedules, app sleeping, health checks, TCP proxy addresses and references to sibling services.

Render

Web, private and worker services with their environment variables and linked env groups, disks, plans and verified custom domains. Postgres and Key Value stores come across with their credentials.

Not imported. Secret files — each one is listed so you can re-add it as a config or a secret variable. Cron jobs, static sites, health checks, pre-deploy commands, autoscaling and stored data.

Vercel

The linked GitHub repository, production branch, root directory, build and install commands, verified custom domains, and plain and encrypted variables for the target you choose.

Not imported. Sensitive variables — Vercel never returns them, so they are listed for re-entry. Serverless and edge functions, middleware, cron jobs and Node version pins.

Vercel projects are importable only when they are linked to GitHub. GitLab, Bitbucket, sourceless and CLI-only projects appear in the listing with the reason they cannot be taken.

The last point is the one that changes how your app runs. On Cloady a Vercel project becomes a long-lived server built by railpack, not a set of functions. buildCommand becomes the build command and installCommand becomes RAILPACK_INSTALL_CMD. If the project is a set of API routes behind a framework that also serves a server, this is usually a no-op. If it leans on edge middleware or per-route function config, plan to fold that into the app itself.

Data is never migrated

Import copies configuration, not content. Volumes, databases and uploaded files stay where they are.

For a Render Postgres or Key Value store, Cloady creates the equivalent app with the same credentials, but it starts empty — dump from the old one and restore into the new one before you cut traffic over.

After the import

Three things are deliberately left for you.

Secrets the provider would not return. Railway sealed variables and Vercel sensitive variables cannot be read back by anyone, including you. They appear under Environment as empty rows labelled Not readable from the provider — enter it again. Fill them in before deploying.

Render secret files. Each is listed as a warning. Re-add it either as a config file in the app's compose or as a secret variable, depending on how your code reads it.

Custom domains. Verified domains are shown so you know what to move, but Cloady does not claim them — that would take your live site down mid-migration. Once the imported app is running and you have tested it on its cloady.io URL, add each domain under Settings → Domains and repoint DNS.

How your token and values are handled

Worth knowing precisely, because you are pasting a credential into a form.

The token travels in the request body, never in a URL, is used for that one call and is never persisted. If the provider returns an error that happens to quote your token back, the text is scrubbed before it reaches your browser.

Your variables' values are not stored when you import. The import returns them to your browser and the generated compose file references them as ${NAME} only. They are written — encrypted — when you press deploy, and not before.

Every imported variable is treated as a secret by default. Cloady only marks one plain when the provider explicitly says so, and even then it stays secret if the name looks like a credential or the value contains a URL with credentials embedded in it. If something ends up hidden that you would rather read, you can flip it afterwards in Variables.

If something goes wrong

A service that uses a private registry image is imported with a warning rather than refused. Cloady cannot carry your registry credentials across, so the pull will fail at deploy until the image is public or available to the cluster.