Migrate from Create.xyz: extract the prompt-to-site into a standard Next/React deploy
Create.xyz stores more than screens. It stores prompt history, design-to-code notes, project-settings names, and a generated app that only reliably boots under Create-hosted preview. Migration is the mechanical extract: get that tree into org Git, replace Publish-GUI assumptions with lockfile CI, and remount Auth off Create preview hostnames. The product journeys stay; the Create publish GUI does not have to.
CodeCross LLC calls migrate-from-create an export-plus-normalization job: pull the generated Next/React tree off Create.xyz, pin Node and lockfiles, turn Create project settings into an env template, and prove a conventional start command on a clean runner. Success is install, test, build, and start with the Create editor shut and Create-hosted publish unused for production.
Why a raw Create export fails on a standard host
A green Create preview is not a portable build
CI images lack packages the preview hid. Start paths assume Create’s working directory. Secrets arrive empty. Auth still expects Create preview hostnames.
Editor-only junk lands in the remote
Caches, local secret files, and prompt notes that never hit disk need an include-or-drop pass. The extract is source, lockfiles, assets, and a written env-name map.
Install only succeeds inside Create’s shell
Replace “available because Create publish” steps with npm ci / pnpm i, build, and a Procfile or Dockerfile CMD. Fail the pipeline if that is not true.
Create .env gets committed “just this once”
Export names into a template. Mint new values on the destination. Rotate old Create secret values after cutover.
Auth and CORS still hardcode Create preview hostnames
Update callbacks before DNS moves. Point the app at a destination database and verify migrations on a clean runner.
The extract sequence that actually boots
Pull, pin, remap, then prove start without Create open
Product behavior stays. Create’s publish GUI and preview assumptions leave. The destination is a conventional start command.
01
Take generated source, lockfiles, assets, and route maps
Leave Create caches and editor-only junk out. Capture Create-tied data requirements separately so CI does not invent schema.
02
Pin Node and encode Create’s start path as a CI job
Version files or the base image. Fail if install only works inside Create’s preview runner.
03
Remap project-settings names; mint destination values
Never commit Create .env. Dual-write or restore data, then verify migrations on a clean runner.
04
Prove install → test → build → start with Create closed
The destination boots from that checkout alone. Create publish is no longer required for production.
How to
Extract a Create.xyz tree into standard Next/React CI
Export-plus-normalization. Success is install → test → build → start with no open Create editor and no Create publish for production.
Step 01
Decide what belongs in the extract versus what stays behind
Take generated source, lockfiles (or generate them), public assets, route maps, and a written map of Create project settings env names. Leave caches, local secret files, and editor-only junk out.
Step 02
Turn Create project settings into portable CI
List env vars and run commands Create assumed. Pin Node. Replace Publish-only steps with npm ci / pnpm i, build, and a Procfile or Dockerfile CMD.
Step 03
Mint destination secrets and remount Auth
Export names into an env template. Never commit Create .env. Update Auth callbacks and CORS that still hardcode Create preview hostnames before DNS moves.
Step 04
Verify migrations on a clean runner
Point the app at a destination database. Capture Create-tied data requirements separately so CI does not invent schema.
Step 05
Prove the destination boots from checkout alone
install → test → build → start with the Create editor closed. Rotate old Create secret values after cutover. Create publish is then optional.
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 belongs in the Create.xyz extract versus what stays behind?
Take generated source, lockfiles (or generate them), public assets, route maps, and a written map of Create project settings env names. Leave Create caches, local secret files, and editor-only junk out of the remote. Capture any Create-tied data requirements separately so CI does not invent schema. Prompt notes that never hit disk need an explicit include-or-drop pass.
How do you turn Create project settings into portable CI?
List env vars and run commands Create assumed. Pin Node in version files or the base image. Replace “available because Create publish” steps with `npm ci` / `pnpm i`, build, and a Procfile or Dockerfile CMD. Fail the pipeline if install only succeeds inside Create’s shell or preview runner.
How should secrets and Auth cutover work during extract?
Export secret names into an env template; mint new values on the destination; never commit Create `.env`. Point the app at a destination database and verify migrations on a clean runner. Update Auth callbacks and CORS that still hardcode Create preview hostnames before DNS moves. Rotate old Create secret values after cutover.
Why does “download the export” without normalization fail on standard hosts?
CI images lack Create-injected packages the preview hid, start paths assume Create’s working directory, and secrets arrive empty. Auth and forms still expect Create preview hostnames. Normalize install, process model, and env first; then push. A green Create preview is not a portable build.
Boot from checkout—not from the Create publish GUI.
Bring the export and the start command Create assumed. We will say whether this is a portable Next/React tree — or a preview that only runs inside Create’s shell.
“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.”