Move what the Emergent agent built onto a repo you control
You made something real with the Emergent AI coding agent. Preview boots. Deploy may already be live. Now you want that full stack on a repo you name — GitHub Save/Push under the org, secrets outside the workspace, React and FastAPI starting without the agent UI. We help you move what you built so Emergent Deploy is no longer the only way it ships.
Leaving Emergent Deploy means this: the code lives in a repo your team owns, preview and production databases are not confused, passwords sit outside the workspace, and someone else can start the app without opening the agent UI. You are done when the next change ships through your CI — not through Deploy in the workspace.
Where people get stuck
A green Emergent Deploy is not a portable full stack
You do not always need every agent chat. You do need a GitHub remote of record, Mongo dumps from the right DB, and secrets that are not stuck in the workspace.
Thinking “Deploy works” is enough
A teammate cloning cold still fails. Lockfiles, FastAPI start, and secrets each need a line — not a memory of your last agent turn.
Mixing preview and production Mongo
On Emergent they are separate. Pointing prod Auth at a preview DB is a cutover failure. Name which DB you export.
Passwords still live in the workspace
Anything only stored in the agent UI is not a safe home. Fresh values on the destination; rotate what touched the workspace.
Only testing the happy preview path
Also try odd roles, cold clone, FastAPI health with the workspace closed, and Expo/EAS paths if mobile ships.
The calm order
Push to GitHub, land secrets and Mongo, prove start, then lean on your host
We do not ban the agent mid-sprint. We make your repo the place real releases come from — after a practiced start and a written way back.
01
Label what stays, what remaps, what is chat-only junk
Proven features stay. Agent shortcuts that only work in the managed shell get replaced. Scratch prompts do not become the architecture story.
02
Stand an org GitHub remote with branch protection
Main protected. Checks must pass. Secrets outside the workspace. Someone else can clone and start.
03
Practice the start path on a clean machine
No leftover agent context. Preview≠prod DB mapped. Sign-in return links move as one set.
04
Sign a short “it still works” note, then shrink Emergent Deploy
Name sample accounts and the primary journey. Time-box how long Deploy-only ship is still allowed.
How to
How to leave Emergent Deploy without guessing
Move code, secrets, and Mongo onto an owned host. Success is a practiced start plus a written way back.
Step 01
List what the workspace still owns
GitHub sync state, env names, preview vs prod DB, Expo config if used.
Step 02
Put an org remote in place before you change habits
Save/Push complete. Secret names sealed. Start commands written down.
Step 03
Build test accounts the demo never used
Odd roles, empty screens, cold clone.
Step 04
Replay real journeys on the destination host
Compare what people see. Freeze the working tree at switch time.
Step 05
Retire Deploy-only ship only after the note is signed
Support knows workspace-era gaps. Time-box going back so two release paths do not invent accounts at once.
Read next
Proof, the essay, and sibling intents
These pages are already on the site. Use them to pressure-test the bet before a call.
“What impressed us most about CodeCross was their ability to deeply understand our vision and translate it into a complete digital solution. Unlike many agencies that just focus on technical delivery, CodeCross approached our project like true partners.”
What should leave agent Deploy, and what workspace junk can stay behind?
Take the thing you built — GitHub-synced source, lockfiles, FastAPI routes, React assets, Expo config if used, and a note of env names. Leave preview caches and workspace-only junk behind. Save Mongo dumps from the correct DB on their own.
How do you make “it Deploys in Emergent” work for the team?
List Python/Node versions and start commands the managed host assumed. Pin runtimes in CI. Replace “available because Deploy” with install, test, build, and a Procfile or Dockerfile for FastAPI plus a React build. Fail the pipeline if install only succeeds inside the managed shell.
How should workspace secrets and Auth/DB cutover work?
Export secret names into an env template; mint new values; never commit workspace secrets. Restore Mongo into the destination cluster. Update Auth callbacks that still hardcode '.emergent.host' or preview hostnames. Rotate old workspace values after cutover.
Why does “clone the GitHub repo” without normalization fail?
CI lacks Emergent-injected env the Deploy hid. Preview DB URLs leak into prod configs. FastAPI start assumes the managed process shape. Secrets arrive empty. Normalize install, process model, DB URLs, and env first. Green Deploy is not a portable build.
Keep what you built. Move it onto a repo you control.
Bring your GitHub sync status, preview vs prod DB note, and a few test accounts. We put owned ship last — and we name the Emergent Deploy path you can roll back to.