Migrating from YepCode Cloud

This guide walks you through running the same workspace you have on YepCode Cloud on your own infrastructure using the YepCode CLI.

The migration relies on three CLI capabilities you already have access to:

yepcode clone downloads your full team workspace (source code, modules, dependencies, variables and datastore) to a local folder you can version with git.
yepcode run executes any process locally, exactly as it would in the cloud.
yepcode http starts a local HTTP server that mirrors the cloud webhook environment and also serves the form schema and submission endpoints, with the same authentication and signature contract.

Step 1 — Install the CLI and clone your workspace

Install the CLI globally:

npm install -g @yepcode/cli

yepcode login
yepcode clone <team-slug>

The clone produces a folder containing processes/, modules/, dependencies/, variables.env, variables.local.env and datastore.json. See the full layout in Clone your team workspace locally.

We recommend committing the cloned folder to a private git repository so you can track changes and roll back if needed.

Step 2 — Configure variables and credentials locally

variables.env lists every team variable name with empty values; variables.local.env overrides those and is git-ignored by default. Fill variables.local.env with the secrets your processes need (database URLs, API keys, etc.). See Team variables for the variable model.

If you were still relying on the deprecated built-in credentials, follow the Deprecated credentials migration guide — the same pattern (dependency package + environment variable) works identically when running locally.

Step 3 — Install dependencies

Install both Python and JavaScript dependencies declared in your workspace:

yepcode dependencies

See Manage package dependencies for the available flags.

Step 4 — Run a process locally

Execute any process by its slug:

yepcode run <process-slug>

By default the input is read from parameters.json inside the process folder. Pass --parameters path/to/parameters.json to override it. See Execute processes locally.

Step 5 — Replace cloud webhooks with `yepcode http`

Start the local HTTP server that replaces the cloud webhook backend:

yepcode http --port 8080 --auth-user admin --auth-password secret

The local server replicates the cloud webhook contract one-to-one:

Same URL shape: /api/<team>/webhooks/<process-slug>.
Same yepcode.context.request (headers, rawBody / raw_body, query, method).
Same signature verification headers (e.g. X-Signature-SHA256, YepCode-Signature) — process code that validates signatures keeps working unchanged. See Webhook executions.

Available flags:

Flag	Default	Description
`-P, --port`	`3000`	Port to listen on
`-l, --logLevel`	`DEBUG`	Log level for process executions (`DEBUG`, `INFO`, `WARNING`, `ERROR`)
`--auth-user`	—	Basic auth username
`--auth-password`	—	Basic auth password
`-j, --jsonLogs`	—	Output process logs as NDJSON

To complete the migration, deploy the cloned workspace and yepcode http on a server reachable from your callers, then update upstream integrations from https://cloud.yepcode.io/api/... to https://your-host/api/....

Step 6 — Repoint your forms

The same yepcode http server exposes the form schema and submission endpoints with the same contract used by YepCode Cloud. The only HTML change required is adding the data-yepcode-form-host-url attribute pointing at your server:

<div
  data-yepcode-form-team="<yepcode-team-id>"
  data-yepcode-form-process="<yepcode-process-id>"
  data-yepcode-form-host-url="https://your-host"
></div>

The same override is supported by the YepCode.initForm(...) JS API and the @yepcode/react-forms component. See Override the API host for all three variants.

Step 7 — Scheduled executions

The CLI does not include a built-in scheduler. To replace YepCode’s scheduled executions, use a host-level cron entry that calls yepcode run (or curl against yepcode http) on the desired cadence.

Example crontab -e entry running my-process every 15 minutes:

*/15 * * * * cd /srv/yepcode/<team-slug> && /usr/local/bin/yepcode run my-process >> /var/log/yepcode/my-process.log 2>&1

On systems without cron you can use the equivalent (systemd timers, Windows Task Scheduler, a CI runner with a scheduled workflow, etc.).

Limitations

Datastore. yepcode clone snapshots your datastore as a single datastore.json file, and local executions read and write that file directly. Concurrency and durability guarantees are whatever your local filesystem provides — there is no transactional store backing it. If your processes rely heavily on the datastore, plan to migrate those keys to an external store (Redis, Postgres, etc.) and switch the relevant code paths.
Audit events, execution history and dashboards. These are not provided by the CLI. If you need them, add your own logging around yepcode run and yepcode http (process logs, NDJSON output via --jsonLogs, reverse-proxy access logs).