Guides / Prompting and shipping

How to Export and Self-Host an AI-Built App

How to get your AI-built app's code out and run it elsewhere: exporting or syncing to GitHub, secrets, moving the database, and choosing a host.

Mythex Team · 2026-09-29 · 7 min read

To self-host an AI-built app, get the code out (a download or a sync to a GitHub repository you own), recreate its secrets as environment variables, move or recreate its database, and deploy it to a host that matches what the app is: a static host for a plain front end, or a platform that runs servers or containers for anything with a back end. The code is usually the easy part. Data, secrets, and the services the builder was quietly running for you are where the work is.

Why export at all

There are good reasons to take your code with you, and some less good ones.

Good reasons:

• Ownership and insurance. A copy of the code in your own repository protects you if the builder changes pricing, features or terms.
• Handoff to developers. An engineering team will want the code in Git, in their usual tools and review process.
• Specific requirements. Data residency, a particular cloud provider, company security policies, or infrastructure the builder does not offer.
• Scale or cost at a size where running your own infrastructure genuinely pays off.

Less good reasons: moving a small app with a handful of users to save a small monthly amount. Self-hosting moves work onto you — updates, backups, monitoring, security patches. That can be the right trade; just make it knowingly.

A sensible middle ground: keep building and hosting where you are, but sync to your own GitHub repository from early on. You get the insurance without the operational work. If Git is new to you, read what GitHub is.

What an export does and does not contain

Before relying on an export, open it and check. Typically:

Secrets are left out on purpose — an archive you might email or commit should never contain live keys. Dependencies are left out because they are rebuilt from the lock file.

Step 1: Get the code out

Two common routes:

• Download an archive of the project. Quick, and fine for a one-off move or a backup.
• Sync to GitHub. Better for anything ongoing: full history, easy to clone anywhere, and most hosts deploy directly from a GitHub repository on every push.

Either way, clone or unpack it on a computer (or a cloud dev environment) and look for a README. If there is none, ask the AI in the builder to write one before you leave:

Write a README for running this project outside this platform: the stack, required runtime versions, install and build commands, the start command and port, every environment variable the code reads (names and purpose, no values), and how database migrations are run.

This one prompt saves hours, because it forces the implicit parts of the setup into writing.

Step 2: Run it locally first

Before deploying anywhere, prove the app runs on its own:

1. Install the runtime the README names — Node.js, Python, Java, .NET — at a matching version.
2. Install dependencies (npm install, pnpm install, pip install -r requirements.txt, or the equivalent).
3. Create a local .env file with the environment variables, using test keys where possible. Keep it out of Git. What environment variables and secrets are explains the idea.
4. Point it at a database — a local Postgres, or a free development database from a managed provider.
5. Run migrations, then start the app and click through the main flows.

Anything that breaks here will break on a host too, and it is much easier to debug on your own machine. Common surprises: a hard-coded URL of the builder's preview, a missing environment variable the builder injected automatically, or a service (file storage, image resizing) that only existed on the platform.

Step 3: Move the data

If the app has real users, the data matters more than the code.

• Export the database. For Postgres, pg_dump produces a file you can restore with pg_restore or psql into the new database. Ask the builder's AI to run it if you do not have direct access, and to explain what it produced.
• Move uploaded files. If users uploaded images or documents, they live in object storage separate from the database. Copy them to your new storage (for example an S3-compatible bucket) and update the stored URLs if they include the old host.
• Plan the cut-over. For a live app, the simple approach is a short maintenance window: stop writes, take a final export, restore it on the new host, switch DNS, then reopen. Write down each step first.
• Test a restore into a scratch database before the real move.

If Postgres is unfamiliar, what Postgres is covers the basics.

Step 4: Choose where to host it

Match the host to what the app is. Names below are examples of well-known providers in each category as of September 2026, not a ranking; check current features and pricing on their sites.

You will also need:

• A managed database — many app hosts offer Postgres, and dedicated services such as Neon or Supabase provide it on its own. Managed is worth it: backups and updates are someone else's job.
• Object storage for uploads, if the app has them.
• Email sending, payments and AI providers — these usually just need the same API keys set on the new host.

Being fair about the trade-offs: platform hosts (the first four rows) are quicker to set up and maintain, but you have less control and costs can rise with traffic. A virtual server is often cheaper at steady load and fully under your control, but you own patching, TLS, backups, monitoring and recovery. If nobody on the team wants that job, choose a platform. For the basics of what hosting involves, see what web hosting is.

Step 5: Deploy and switch over

1. Connect the repository to the host, or push a container image.
2. Set environment variables in the host's dashboard — every one from your README, with live values.
3. Set the build and start commands and the port. Many hosts pass the port in a PORT environment variable; the app should listen on it and on all interfaces (0.0.0.0), not only localhost.
4. Run migrations against the new database.
5. Test on the host's temporary URL before touching DNS.
6. Update external services that point at your old URL: payment webhooks, OAuth redirect URLs for login, email links, allowed origins.
7. Move the domain by updating DNS records to the new host. How to connect a custom domain explains the records.
8. Keep the old deployment running briefly until you are sure, then take it down.

Step 6 is the one most often forgotten: logins and payments that silently fail after a move usually trace back to a callback URL still pointing at the old host.

Step 6: Take over the operations

Once you self-host, the things the builder handled become yours. At minimum: automatic database backups with a tested restore, error tracking, uptime alerts, dependency updates, and a note of who has access to each account. How to take an AI prototype to production walks through this list in more detail.

Export checklist

• Code in a repository you own, with a README covering run, build and env vars
• App runs locally from a clean clone
• Database exported and restore tested; uploaded files copied
• Host chosen for the app's shape, plus managed database and storage
• All environment variables set with live values on the new host
• Webhooks, OAuth redirects and email links updated
• DNS switched, old deployment kept briefly, then removed
• Backups, monitoring and access list in place

Exporting from Mythex

On Mythex you own the code you build. On the Pro plan you can download the project as an archive from Project settings → Export, or connect GitHub and push and pull against your own repository; Free plans can view the code read-only but not export or sync. Secrets and node_modules are left out of exports, so recreate your secrets on the new host. The docs cover the steps in export and run elsewhere and GitHub, export and import. You can also keep hosting on Mythex and use GitHub sync simply as your own copy and handoff route; if you do move, unpublish the Mythex app once the new host is live.