# Migrating from YepCode Cloud

> Run your YepCode workspace on your own infrastructure using the YepCode CLI.

This guide walks you through running the same workspace you have on YepCode Cloud on your own infrastructure using the [YepCode CLI](/docs/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

[Section titled “Step 1 — Install the CLI and clone your workspace”](#step-1--install-the-cli-and-clone-your-workspace)

Install the CLI globally:

```sh
npm install -g @yepcode/cli
```

Log in and clone your team workspace:

```sh
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](/docs/cli#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

[Section titled “Step 2 — Configure variables and credentials locally”](#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](/docs/processes/team-variables) for the variable model.

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

## Step 3 — Install dependencies

[Section titled “Step 3 — Install dependencies”](#step-3--install-dependencies)

Install both Python and JavaScript dependencies declared in your workspace:

```sh
yepcode dependencies
```

See [Manage package dependencies](/docs/cli#manage-package-dependencies) for the available flags.

## Step 4 — Run a process locally

[Section titled “Step 4 — Run a process locally”](#step-4--run-a-process-locally)

Execute any process by its slug:

```sh
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](/docs/cli#execute-processes-locally).

## Step 5 — Replace cloud webhooks with `yepcode http`

[Section titled “Step 5 — Replace cloud webhooks with yepcode http”](#step-5--replace-cloud-webhooks-with-yepcode-http)

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

```sh
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](/docs/executions/webhooks).

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

[Section titled “Step 6 — Repoint your forms”](#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:

```diff
<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](/docs/forms/customization#override-the-api-host) for all three variants.

## Step 7 — Scheduled executions

[Section titled “Step 7 — Scheduled executions”](#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:

```sh
*/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

[Section titled “Limitations”](#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).