Skip to main content
There are three ways to bring something you already have onto InstaPods. Each one tells you what it will and will not carry across before it runs, in the dashboard, in the CLI, and here. Start at Import in the dashboard sidebar (or /dashboard/import).

​
The one thing to read first

No import path moves any of this, on any platform: An importer that quietly skipped one of these would be worse than no importer, so every path prints the list and the dashboard shows it beside the deploy button.

​
1. A GitHub repository

The main path, and the one that keeps you portable: your repository stays the source of truth and InstaPods deploys from it. You can point another host at the same repo at the same time.
  1. Paste the repository URL into the GitHub repo tab and press Check.
  2. We read the repo’s root files and tell you the runtime we detected.
  3. Read the transfer summary, then Continue in the deploy wizard, where you set the branch, environment variables, and the install/build/start commands (all editable).
Private repositories work: the wizard connects GitHub and clones with a scoped token. Comes across: everything committed to the branch, the detected build, the environment variables you enter, and push-to-deploy via a webhook. Doesn’t: anything in .gitignore (which is where the real .env almost always is), and any process beyond the single service a pod runs.

​
2. A live URL (static snapshot)

For a site whose hosting costs more than the site earns — a brochure site, a small WordPress install nobody edits any more. We fetch the pages a visitor can reach from the URL you give us, download the images, CSS, JavaScript and fonts on the same domain, rewrite those references to point at the pod, and serve the result as static files.
  1. Put the homepage URL into the Live URL tab.
  2. Set how many pages to save (25 by default, 1 for a single page, 100 maximum).
  3. Preview — it lists exactly which pages and assets were saved, and how big they are.
  4. Deploy.
Comes across: the HTML your server returns, and same-domain assets. Doesn’t:
  • Anything that runs on the server — forms, search, comments, logins, carts, the admin area. There is no PHP and no database behind a snapshot.
  • Your CMS. This copies the output, not the system that produced it; to change content you edit the files or re-run the import.
  • Pages behind a login, and pages nothing links to.
  • Content JavaScript builds after the page loads — we save what the server sends.
  • Assets on other domains. A CDN or third-party script keeps pointing at that domain.
Only snapshot a site you own or have permission to copy. We identify ourselves as InstaPods and respect the site’s robots.txt; a site that disallows us is not copied.
If the crawl hits the page, size or time limit, it stops and says so — and every link to a page it didn’t save keeps pointing at your original site, so nothing 404s while you check the result. The output is a plain folder of files. You can download it from the pod’s backups and host it anywhere.

​
3. Lovable, Replit, Vercel and friends

None of these expose your project to a URL a server can fetch — the source sits behind an authenticated API — so pasting a project link imports nothing anywhere, including here. Each one does have an export. Open the Another platform tab for the steps, or read them below.

​
Lovable

Connect the project to a GitHub repository you own (Lovable pushes the whole generated project and keeps pushing as you keep editing), then deploy that repository from the GitHub tab. Your Supabase project does not move — database, auth, storage and edge functions stay in Supabase. That’s usually what you want, but it means your data still lives with a second provider and you still need your own backups of it. Re-enter the Supabase URL and anon key as environment variables or the deployed app can’t reach it.

​
Replit

Push the Repl to GitHub from the Git pane (or use ⋮ → Download as zip and the wizard’s Upload ZIP step). Copy your Replit Secrets out before you leave — they’re in neither the repository nor the zip, and if you lose access to the Repl you lose the values. Export anything in Replit DB or an attached database for the same reason. Your .replit run config doesn’t transfer either; check the start command we detect matches what the Repl actually ran. This is the “GitHub plus a database you control” setup people recommend for exactly this situation: the repository and the database are both yours, independent of where the app runs.

​
Vercel

A Vercel project already builds from a Git repository, so there’s nothing to export — copy the repo URL from Settings → Git and deploy the same repository here. Copy Settings → Environment Variables too (Vercel hides existing values, so you may need the originals). A pod runs one long-lived server. A Next.js app runs with next build + next start and its API routes keep working. Standalone serverless and edge functions, Vercel KV/Blob/Postgres/Cron, ISR and edge-caching behaviour, preview deployments and Vercel-managed domains do not have an equivalent — plan for each of those before you switch DNS. Deploying here doesn’t disconnect Vercel. Run both while you check the pod behaves the same.

​
Netlify, Bolt, v0

Same shape: Netlify and Bolt go through GitHub (Netlify Functions, Forms, Identity and _redirects rules don’t transfer); a single v0 component goes through the Paste tab, and a whole v0 project through GitHub.

​
From the CLI

Without --dry-run, the CLI prints the same summary and asks you to confirm before creating a pod. Pass -y to skip the prompt in a script; the prompt is skipped automatically when stdin isn’t a terminal.

​
The catalog as data

GET /api/imports/sources returns every route in, every guided platform, and the transfer summary for each. Pass ?url= and it also tells you what it would do with that URL. The dashboard, the CLI and this page all read from it, so they can’t disagree about what an import carries.