Deploying

One command takes an app directory to a live capability. Where the platform reviews releases, it goes live once the release is approved.

revenexx deploy app

Run it from the app directory — the one containing manifest.json.

The five steps

1. Register if new — finds the app by name, or creates it.
2. Upload — packs the directory and uploads it.
3. Build — the platform builds the deployment and waits for it.
4. Publish — makes the version available in the Marketplace.
5. Install — installs it on the target tenant.

Where the platform reviews releases, the command checks the release round (the platform's review of this upload) after the build. Steps 4 and 5 run only once the release is approved. If it is still in review, the command stops after the build and prints a resume command. See When the release waits for approval.

The build is where your declarations are applied: the schema diff runs, the capabilities are registered, and the publish-time rules are checked. The install is where your routes are written — see Publish and install.

The entrypoint is src/main.js.

Flags

--runtime and --specification apply only to a first-time registration. Passing them to an existing app does nothing — changing the runtime or the compute size of a registered app is done on the app itself, in App Studio, not on a deploy.

Run revenexx deploy app --help for the live list.

Bump the version first

Every successful build needs a version nobody has used before, so the bump is part of the deploy:

# 1. bump `version` in manifest.json
# 2. regenerate, if the schema changed:
revenexx apps capabilities --write
revenexx apps generate
npm test
# 3. deploy
revenexx deploy app

See Versioning.

Targeting an environment

There is no --env flag. You scope a deploy by selecting the tenant first:

revenexx tenants use acme-staging
revenexx deploy app

# verify, then:
revenexx tenants use acme-production
revenexx deploy app

The last tenants use stays saved: afterwards every repo on your machine deploys to acme-production until you switch back, and REVENEXX_TENANT or a tenant: in .revenexx.yaml won't change that. To target one deploy without saving anything, pass the flag instead: revenexx deploy app --tenant acme-staging. See how the tenant resolves.

--owner <tenant> changes only the tenant the install runs on; the upload and the build still go to the tenant the CLI resolved. A CI job names the tenant for that one command with --tenant, and for the install with --owner:

revenexx login --token "$REVENEXX_API_KEY" --tenant "$REVENEXX_TENANT"
revenexx deploy app --tenant "$REVENEXX_TENANT" --owner "$REVENEXX_TENANT" --timeout 900 --json

A release still in review ends the command without an error and with nothing published, so a CI job that checks only the exit code goes green. With --json, read published and installed instead (both false while the release waits), then release.state, which is null when no round is recorded; see In CI.

Always deploy to a tenant with real-shaped data before production. A mock adapter cannot tell you that a new notNull column will not apply to a populated table.

Never run deploy app on a git-wired app

If an app's deployments come from a connected repository, revenexx deploy app will still work — it uploads a tarball, and the active deployment loses its commit association. The app keeps running; the link between what is deployed and what is in git is gone.

Pick one path per app:

Mixing them is the failure: after one CLI deploy onto a git-wired app, nobody can tell which commit production is running.

If it has already happened, the fix is to redeploy from the connected branch so the association is re-established. Nothing is lost except the audit trail for that one version.

There is no apps register step

revenexx apps register --manifest manifest.json does not work. That command needs a function-id and a runtime, neither of which an app manifest carries, so it fails whatever you pass it.

Registration is the first step of revenexx deploy app and needs no separate command.

If you do reach for the lower-level commands, note that they are revenexx apps <verb> with no apps- prefix on the verb — revenexx apps create-deployment, revenexx apps list-deployments, revenexx apps publish. See the apps command reference.

When the deploy fails

A release checklist

1. Bump version in manifest.json, honestly.
2. Validate the JSON files against https://schemas.revenexx.com/… — your editor does this if you set $schema. See Validate.
3. Regenerate: revenexx apps capabilities --write and revenexx apps generate. Commit the diff.
4. Run the app's tests against the mock adapter, then once against a dev tenant with the remote adapter for the fidelity a mock cannot give you. See Testing.
5. revenexx tenants use <staging> and revenexx deploy app. If it warns that the release is waiting, check revenexx release status and run the resume command it printed once the release is approved.
6. Call /defaults, then exercise the new capabilities against the staging tenant. See Verifying live.
7. Open the app in the Cockpit: views render, existing data survived, no console errors.
8. revenexx tenants use <production> and revenexx deploy app, finishing a held release as in step 5.
9. Repeat step 6 against production.

Next steps

• Publish and install — what steps four and five really do.
• Verifying live — the calls to make afterwards.
• Operating — the deployment and execution screens.
• Scaffolding — create and deploy in the CLI reference.
• Deploy and verify an App — the same path as a walkthrough.