---
title: Release your app
slug: optimizely-connect-platform/docs/releasing
docTags: 
createdAt: 2026-07-23T12:37:03.354Z
---

When your app is ready, validate and publish it to the OCP **App Directory**. To release it publicly, submit it for review by Optimizely.

For details on preparing, publishing, and installing, see [Prepare, publish, and install](docId\:Bi9Hif758LHEoTG2iflfY).

## Release options

When you release your app, choose one of the following options:

- **Normal version** – Remove the pre-release tag, such as `1.0.0`. The app is publicly available to all Optimizely customers in the **App Directory** after review approval.
- **Private version** – Use the `-private` tag, such as `1.0.0-private`. The app is released to production, but availability is limited to selected OCP accounts. Use this when you want to release production-ready functionality but control who can install the app. Private versions also require review approval. To install a private version to selected accounts, use the `ocp directory install` command:

```shell
ocp directory install YOUR_APP_ID@1.0.0-private TRACKER_ID
```

To install the app on an instance, you need a role for that OCP instance. See [Developer accounts and organizations](https://docs.developers.optimizely.com/optimizely-connect-platform/docs/get-started-with-the-ocp2-developer-platform#developer-accounts-and-organizations) for information on getting access and access levels.

## Validate, prepare, publish, and install

1. Validate your app configuration by running `ocp app validate` in the CLI.
2. Run `ocp app prepare` to prepare your app for publishing. This initiates the code review process. When you run this command with a release version, the CLI prompts you to confirm:

```text
You are uploading a release version of the app. This will start a review process and the app can't be published until it is approved. Are you sure?
```

Enter *yes* to proceed. When your app is approved (review takes one to two business days), proceed to step 3.

3. Publish the app to the OCP **App Directory** by running `ocp directory publish YOUR_APP_ID@1.0.0`. See [App versioning](docId\:OS9StLD5GccO3vLVpMzPv) for details on versioning your app.
4. Run `ocp directory install YOUR_APP_ID@1.0.0 TRACKER_ID` to install the app into your OCP account. Replace `TRACKER_ID` with your OCP account [tracker ID](docId\:dqezUfcA92mWm_cMHggJP). For example, `ocp directory install YOUR_APP_ID@1.0.0 Z6jCndly_E2WzpvDkcKBKA`.

View your app listing in the OCP **App Directory**.

## Release with `ocp app deploy`

:::hint{type="danger"}
**Experimental**

`ocp app deploy` and `ocp app promote` are experimental and require `runtime: node22` or later in `app.yml`.
:::

If you develop on a [preview track](docId\:gLoc5c6DPRHSfUcBL6bpf), the version on the track is not a release. The **App Directory** lists preview versions only for accounts that install or follow them.

To release a semantic version (semver), run the following command from your app directory:

```shell
ocp app deploy --version 1.0.0
```

The command builds the release version from your working directory and starts the [app review process](docId\:Cy5csTL4qYT3mfYQ92hH4). It replaces setting the version in `app.yml` and running `ocp app prepare` and `ocp directory publish`. The first run stops at the review. After approval, rerun the same command to publish. Add `--watch` to wait for approval and publish when it arrives.

Alternatively, release the code a track already runs, instead of your working directory, by promoting the track to a semver version:

```shell
ocp app promote --from dev/USERNAME --to 1.0.0
```

See [Release a semver version](docId\:gLoc5c6DPRHSfUcBL6bpf) for details.

## App review process

:::hint{type="info"}
**Note**

The app review process typically takes one to two business days to complete.
:::

Running the `ocp app prepare` command with normal, beta, or private versions initiates the app review process. Releasing a semver version with the experimental `ocp app deploy --version` or `ocp app promote` commands also initiates it.

The Optimizely App Review team invites you to a GitHub repository containing your app code. When you accept the invitation, you can see the pull request and feedback from Optimizely engineers as they review your code.

:::hint{type="info"}
**Note**

GitHub notifies you by email about any activity in your app review repository.
:::

If Optimizely determines that changes are required, Optimizely submits a GitHub pull request. After you make the requested changes, run `ocp app prepare` in the OCP CLI again with the same version. This updates the pull request with the latest code from your app.

This review ensures your app meets design guidelines, content guidelines, and security requirements so customers can safely use your app.

### Best practices

Your app should meet the following guidelines before you submit it for review:

**Security**

- Your app cannot contain any secrets or credentials. Store secrets in environment variables, in a `.env` file outside of GitHub.
- Your app cannot log secrets or credentials.
- The `.env` file cannot be part of the repository.
- Your app cannot import PII data.
- Your app cannot scan the engine code or invoke internal engine code other than through the API defined in the App SDK.
- Your app cannot execute any OS commands directly.
- Your app cannot gather, log, or send any information about how the runtime is built (OS version, folder structure, networking, ports, and so on).

**app.yml**

- Your app must accurately identify itself in the metadata section. The `app_id`, `display_name`, and `summary` should clearly identify the app and its purpose.
- All URLs you define in the metadata must be valid, functioning URLs.
- Define the partner developing the app in the `vendor` field.

**Jobs**

- The `perform` method should complete in under 60 seconds.
- The `prepare` method should handle initializing and resuming the job.

**Logging**

- Use `logger` for logging, not `console`.

**src/schema**

- Prefix all objects and fields unique to your app with your app ID.

**Storage**

- Your app cannot store data outside of OCP. Use available storage instead.
- Only store secrets in the [secrets store](docId\:Fg0htEGqcx00Vcvflv-lB).

### Track your app review in GitHub

When you submit your app for review, GitHub sends you an email inviting you to your app's repository in `Optimizely-Connector-Platform-AppReview`. Accept the invitation to participate in the review. GitHub notifies you each time Optimizely comments on your review or requests changes.

Communicate directly with the reviewers in GitHub throughout the review process.

### Check review status in the OCP CLI

Run the following command in the OCP CLI to view your app's review status:

```shell
ocp directory status APP_REVIEW_ID@APP_VERSION
```

### Open GitHub review from the OCP CLI

Run the following command in the OCP CLI to open the GitHub review in your browser:

```shell
ocp review open APP_REVIEW_ID@APP_VERSION
```

### Change requests during app review

During the review, Optimizely may submit change requests through GitHub. To make the requested changes:

1. Change the version of your app in [app.yml](docId\:M8TiC_ggD3UbZu73jyhGi) back to a dev version by adding the `-dev` tag. For example, if the app version you submitted for review was `0.0.1`, change it to `0.0.1-dev.1`.

:::hint{type="info"}
**Note**

Maintain the same version number (for example, `0.0.1`) throughout the review. Changing the version number creates a new review repository.
:::

2. Make the requested changes, then test your app internally with the `-dev` tag.
3. Remove the `-dev` tag from the version in [app.yml](docId\:M8TiC_ggD3UbZu73jyhGi).
4. Run the following command in the OCP CLI to resubmit your app to the existing review:

```shell
ocp app prepare
```

Continue monitoring the review in GitHub and making the requested changes until your app is approved.

### Release publicly

When Optimizely approves your app, run the following command in the OCP CLI to release your app publicly:

```bash
ocp directory publish ocp_quickstart@1.0.0
```

Your app is then available in the OCP App Directory for all Optimizely customers.

## Versioning after release

After your initial release, publish updates using the same versioning scheme:

- `PATCH` versions like `1.0.1` – Bug fixes that require a review.
- `MINOR` versions like `1.1.0` – Feature additions that auto-upgrade existing installations after review approval.
- `MAJOR` versions like `2.0.0` – Breaking changes that require a review.

See [App versioning](docId\:OS9StLD5GccO3vLVpMzPv) for details on how OCP handles version upgrades and the `-dev` workflow.