★★★★★ 4.8 CE

BuildShip Migration & Switching Guide 2026

BuildShip exports every API as OpenAPI and your Script nodes are standard JS/TS, but the runtime stays on its cloud. Bring your own Postgres to keep data outside.

Website BuildersVerified today

Full review Pricing Official site ↗

BuildShip Migration verdict

Verified today·7 sources checked

BuildShip lets your logic leave, but not the running backend itself.

You can export every shipped API as an OpenAPI spec, in JSON or YAML, and your Script nodes are standard JavaScript or TypeScript that lift straight out. Data was never imprisoned either, since you can point at your own Postgres, Supabase or MySQL instead of the bundled Firestore.

How to plan the move

Choose BuildShip when you want fast backend assembly and accept that the runtime is managed, while keeping a clean exit for the contract via OpenAPI and the logic in JS or TS. It is less ideal if you require the ability to self-host the whole backend later, since the orchestration cannot leave BuildShip's Google Cloud, only the artifacts can.

Honest limits

The running backend is not self-hostable, since workflows execute on BuildShip's Google Cloud runtime, so leaving means rebuilding the orchestration.
The API contract is portable via OpenAPI export, in JSON or YAML, and Script nodes are standard JS or TS you can lift out. Data ownership depends on your choice, since BuildShip ships Firestore, but a bring-your-own Postgres, Supabase or MySQL keeps records outside BuildShip.
Version control saves a restorable version per Ship, but trigger revisions are not versioned.

API contract export: OpenAPI (JSON/YAML)
Logic export: Standard JS/TS
Database: BYO (or Firestore)
Versioning: One per Ship
Lock-in ceiling: Runtime on GCP

View sources

This page covers migrating in and out of BuildShip. SEO output and pricing live on their own pages.

What moves into BuildShip, and can you leave?

Migration & portability receipt

Pick what you are bringing to BuildShip, and see exactly what transfers.

Migration read3 transfer, 1 need hand work

Existing backend/API import: does not transfer, no importer; rebuild workflows in the editor.
Database: imports natively, Firestore by default, or bring your own Postgres/Supabase/MySQL.
Custom code: imports natively, Script nodes are standard JS/TS with NPM imports.
Frontend connection: imports natively, shipped workflow exposes an API url for your frontend.

Cutover steps, in order

1Export the OpenAPI spec, Project Settings > APIs > JSON/YAML.
2Lift the Script-node code, standard JS/TS modules.
3Confirm data ownership, BYO database keeps records outside BuildShip.
4Rebuild orchestration on target, runtime is not portable off GCP.
5Repoint the frontend base URL, same request contract.

Every row is a documented import/export capability from BuildShip and the source platforms, not an effort estimate.

BuildShip migration configuration

BuildShip exports the entire structure of your shipped APIs as an OpenAPI Specification in JSON or YAML, from Project Settings > APIs. That file is your portable API contract: feed it to a client generator, an API gateway, or a rebuild on another platform. (The reverse, importing OpenAPI into BuildShip, is still under development.)

Export the OpenAPI spectext

# In BuildShip: Project Settings > APIs tab > select workflow(s)
#   > export dropdown (top right) > choose JSON or YAML > download.
#
# You get a standard OpenAPI document, e.g.:
openapi: 3.0.0
paths:
  /story-gen:
    post:
      requestBody: { content: { application/json: { schema: { ... } } } }
      responses: { '200': { description: OK } }
# Use it to generate clients or rebuild the contract elsewhere.

Script nodes run standard JavaScript/TypeScript and import NPM packages, so each one is a normal module you can copy out of BuildShip and run anywhere. This is the logic half of your migration, no proprietary blob to reverse-engineer.

A Script node is portable JS/TSjavascript

// A BuildShip Script node is plain JS/TS with NPM imports, lift it out as-is.
import { toDataURL } from 'qrcode';

export default async function generateQRCode({ url }) {
  const qrCodeDataURL = await toDataURL(url);
  return qrCodeDataURL;
}
// Re-wire its inputs/outputs in your target runtime; the code itself is portable.

Because the frontend only knows the endpoint URL, the cut-over is a base-URL swap. Keep the same request shape your BuildShip REST trigger used (default POST, application/json) and point it at the rebuilt backend. The orchestration is what you rebuilt; the contract stayed the same via the OpenAPI export.

Repoint the frontend (cut-over)javascript

// Before: calling the BuildShip endpoint
const BASE = 'https://008vd0.buildship.run';
// After: same contract, your rebuilt backend
// const BASE = 'https://api.your-domain.com';

await fetch(`${BASE}/story-gen`, {
  method: 'POST',                                   // BuildShip REST default
  headers: { 'Content-Type': 'application/json' },  // BuildShip default
  body: JSON.stringify({ prompt, style }),
});

What moves when you migrate to/from BuildShip

Migration element	On BuildShip	Detail	Source
API contract (out)	OpenAPI export (JSON/YAML)	Export the entire structure of your shipped APIs for integration with other tools/frontends	—
Business logic (out)	Standard JS/TS	Script nodes are written in JavaScript/TypeScript with NPM imports, so the logic lifts straight out	—
Workflows & nodes	Copy/paste as schema	Copy whole workflows and individual nodes across projects, or within a project	—
Database	Bring your own	A project ships with Firestore, but you can use Postgres, Supabase, MySQL or any database instead	—
Version history	One version per Ship	Every Ship creates a restorable version of the workflow you can compare and revert to	—
Running backend (out)	Stays on BuildShip	Workflows execute on BuildShip's GCP runtime; there is no self-hostable export of the backend itself	—

Source-to-BuildShip mapping

What you are moving	Where it lands	Caveat	Source
Shipped API	OpenAPI spec file (JSON/YAML)	Export from Project Settings > APIs; import-OpenAPI is still under development	—
Script node logic	Standard JS/TS module	Real code with NPM imports; re-wire its inputs/outputs in the target	—
HTTP node call	A plain HTTP request	Method and params are UI-configured; reproduce as a normal request in code	—
Data records	Your own database	If you used BYO Postgres/Supabase/MySQL the data never lived inside BuildShip	—
BuildShip Tables data	A Firestore database	The default store is Firestore; migrate it as you would any Firestore collection	—
Workflow orchestration	Stays on BuildShip's GCP	No self-hostable runtime; you rebuild the orchestration on the target platform	—

BuildShip migration timeline and rollout

Phase	What happens	Effort	Source
1. Export the API contract	OpenAPI spec (JSON/YAML)	Low, a download from Project Settings	—
2. Lift the logic	Copy Script-node JS/TS out	Low to medium, it is standard code with NPM imports	—
3. Confirm data ownership	Point at your own database	Low if you used BYO Postgres/Supabase/MySQL	—
4. Rebuild orchestration	Recreate workflows on the target	High, the runtime is not portable off BuildShip's GCP	—
5. Cut over endpoints	Repoint the frontend's API calls	Low, swap the base URL the frontend uses	—

What to verify before you commit to BuildShip

Your API contract and logic are portable: export the OpenAPI spec and lift Script nodes as standard JavaScript, so neither the interface nor the code is trapped
The running backend is not portable: workflows execute on BuildShip's Google Cloud runtime and there is no self-hostable export, so leaving means rebuilding the orchestration on the target
Keep your data in your own database: a project ships with Firestore, but choosing Postgres, Supabase or MySQL means the records never lived inside BuildShip and nothing needs rescuing
Version history does not cover everything: every Ship creates a restorable workflow version, but the version history for trigger revisions is not available, so document trigger changes separately

BuildShip Migration FAQ

Can I export my BuildShip APIs?

Yes, as an OpenAPI Specification. From Project Settings, APIs you export the entire structure of your shipped workflows in JSON or YAML. That is your portable API contract for client generation, an API gateway, or a rebuild elsewhere. The reverse direction, importing an OpenAPI spec into BuildShip, is still under development.

Is my BuildShip logic locked in?

The logic is not, the runtime is. Script nodes are standard JavaScript or TypeScript with NPM imports, so each one is a normal module you can copy out and run anywhere. What you cannot export is a self-hostable version of the backend itself, because workflows execute on BuildShip's Google Cloud runtime. Leaving means lifting the code and contract, then rebuilding the orchestration.

Where does my data live in BuildShip?

Wherever you choose. Every project comes with a ready-to-use Firestore database, called BuildShip Tables, but you can pick your own Postgres, Supabase, MySQL or any database. If you bring your own, the records never lived inside BuildShip, so there is nothing to extract on the way out, since you already hold the data.

Can I self-host a BuildShip backend?

No. The portable parts are the OpenAPI contract and the Script-node code, but the workflow runtime runs on BuildShip's managed Google Cloud and is not offered as a self-hostable deployment. If self-hosting the whole backend is a requirement, treat BuildShip as a fast way to build and ship, and plan an orchestration rebuild if you ever need to move off it.

How hard is it to move off BuildShip?

It is an extraction plus a rebuild, not a data rescue. Export the OpenAPI spec, lift your Script-node JavaScript, confirm your data is in a database you control, then recreate the workflow orchestration on the target and repoint the frontend's base URL. The contract and logic come across cleanly, while the orchestration is the work, because the runtime stays on BuildShip.

Sources & verification

Verified by ComparEdgeMethod: Vendor docs, official pages, and selected independent sources

Source	What was checked	Last checked
Buildship Official	Official product page	July 10, 2026
Buildship Developer docs	API Spec	July 10, 2026
Buildship Developer docs	Core Nodes Script	July 10, 2026
Buildship Developer docs	Copy Paste	July 10, 2026
Buildship Developer docs	Buildship Tables	July 10, 2026
Buildship Developer docs	Version Control	July 10, 2026
Buildship Developer docs	Workflows Workflow 101	July 10, 2026

Every fact on this BuildShip page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.