Knowledge base
Everything you need, step by step
How to use BeyondCode Deploy as a client or team member, understand current route qualification, and prepare source handoffs for builders, closed platforms, and portable deployments.
For clients
Using the client portal
01
Create your account
Register with the same email BeyondCode has on file for your project. You'll receive a one-time code by email — enter it to finish verification.
02
Sign in to your portal
After signing in you land on your portal home. It lists every project tied to your email — nothing else is visible to you or anyone else.
03
Respond to approvals
When a release needs your sign-off, a banner appears at the top of your portal. Open it, review the notes, and approve or request changes — releases wait for you.
04
Track each release
Every project card shows where it's live and its release progress — Pending → Staging → Production — tied to an exact version and commit.
05
Test and give feedback
When a staging release is ready, rate it and leave testing notes right from the portal. Your feedback goes straight to the team's queue.
06
Access your files
Deliverables, documentation, and handover files live under Files in your portal — downloadable any time, no request needed.
07
Manage billing
Your plan, status, and upgrade options are under Billing. Changes go through a secure Stripe checkout — we never see your card.
For the team
Running a deployment, end to end
01
Create the project
From Projects, add the project with the client's email — it appears in their portal automatically, with a default handoff checklist.
02
Define the release and target
Add a release with the exact version and commit SHA, plus a deployment target (provider, environment, URL). Staging before production is enforced.
03
Work the checklist
Export, deploy, and verify items track readiness. Preflight blocks dispatch until they're complete — no half-ready release can ship.
04
Request client approval
Create an approval request; the client responds from their portal. A production dispatch requires an approved release first.
05
Run preflight
The 9-point preflight validates scope, repository, immutable commit, environment match, credential boundary, approval, and checklists in one pass.
06
Dispatch the job
For a qualified provider route, dispatch sends a signed, idempotent job to the deployment runner and records the result. For destinations that are not yet provider-qualified, the release stops at the portable handoff or assisted deployment step instead of pretending automated execution succeeded.
07
Health checks and evidence
A scheduled health check verifies live URLs and flags failures. Every step — preflight, dispatch, health — is recorded as evidence tied to the job.
08
Hand off
After production acceptance, mark the release live, share handover files through the client's Files page, and confirm ownership of the repository, hosting, data, and credential-management path. Raw secrets are not copied into handoff documents.
Bubble migrations
Rebuilding a Bubble app, step by step
Bubble has no conventional source export. Data, workflows, privacy rules, plugins, files, and integrations are captured explicitly; migration and reconstruction are verified step by step rather than assumed.
01
Do your prep work
Bubble has no conventional code export, so part of the work is capture: export the data available to you, preserve an app backup/version, list plugins and API connectors without pasting secret values, and document privacy rules. See the Bubble guide under Source handoff.
02
We inventory your workflows
Bubble workflows live only inside the editor, so they can't be migrated automatically. We walk the workflow list with you and log every one — its trigger (button click, schedule, data change…), its actions, and its conditions — into a workflow inventory.
03
Each workflow gets a target
Every inventoried workflow is mapped to its portable replacement: frontend event handlers, backend functions, scheduled workflows, entity-triggered automations, or the email service. Anything that doesn't map cleanly is flagged as a manual rebuild item.
04
Nothing ships un-mapped
The rebuild can't be approved while any workflow is still pending review — every one must have a target or be explicitly flagged for the manual rebuild checklist. That's what makes a Bubble migration scoped and quoteable.
05
Data, then rebuild
Structured data exports can be migrated through the approved data-migration job and reconciled before cutover; this is not guaranteed to be fully automatic for every Bubble schema. The application behavior is reconstructed on the agreed portable stack and verified against the captured inventory.
06
Manual rebuilds land in the handoff
Workflows that couldn't be translated — complex conditionals, niche plugins — appear as items on the handoff checklist so they're rebuilt, verified, and visible rather than silently dropped.
Source acquisition
Preparing a source handoff
Every platform is different. These guides explain the source boundary we can work from. A guide describes the handoff mechanics; it does not by itself mean that every builder-to-destination route is live-qualified.
Public-beta qualification
What is proven today
Runtime deployment: Railway live-certified; Render currently blocked
Base44, Replit, Hercules, and Lovable portable runtimes have completed live destination acceptance. This proves the deployment route, not automatic transfer of every hosted user, record, file, workflow, or provider integration.
Fixture-qualified / preview
Bolt, StackBlitz, v0, Cursor, and Codex have passed pinned-source fixture qualification. CodeBuddy is preview. These statuses are narrower than a live builder-account export plus destination acceptance.
Deep-state migration: separately gated
A deep migration must account for users/profiles, roles and permissions, tenant memberships, auth policy, records, files, functions, workflows, schedules, integrations, webhooks, and configuration. BeyondCode uses a normalized deep-source bundle and per-provider adapters; missing critical state blocks production qualification.
Other destinations and closed platforms
Other destinations can receive a portable Git + Docker handoff until automated provider execution is separately qualified. Bubble and similar closed platforms use assisted capture and reconstruction rather than a fictional code export.
Still stuck?
Open Support for account-aware troubleshooting, or start a project intake if you have not created a migration yet.
Open Support