> ## Documentation Index > Fetch the complete documentation index at: https://docs.instapods.com/llms.txt > Use this file to discover all available pages before exploring further. # Import an existing app > Bring an app you already have — a GitHub repository, a live site, or a Lovable, Replit or Vercel project — onto InstaPods, and know exactly what does and doesn't come with it. 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: | Not imported | What you do instead | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Your database and its contents | Export it from wherever it lives now; restore it into a managed database on the pod, or leave the app pointed at the database you already run. | | Secrets, API keys, connection strings | We have no access to them. Re-enter them in the wizard; anything you don't paste, the app won't have at runtime. | | Auth and identity configuration | Add the pod's URL as an allowed OAuth callback in each provider, and re-issue any session secret. | | Files the running app wrote (uploads, caches) | Copy them across yourself — they're on the old host's disk, not in your source. | | Background jobs, workers, cron | A pod runs one service. Set the rest up on the pod after the first deploy. | | Your domain and DNS | The pod gets its own HTTPS URL immediately; your domain keeps pointing at the old host until you change the record. | 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**. ```bash theme={null} instapods import https://example.com --site instapods import https://example.com/pricing --site --pages 1 instapods import https://example.com --site --dry-run ``` **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 ```bash theme={null} # What would this import bring, and what would it leave? Creates nothing. instapods import https://example.com --site --dry-run ``` 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.