Deploying

revenexx deploy app end to end — what the five steps do, every flag, targeting an environment, git-wired versus tarball, and why there is no apps register step.

One command takes an app directory to a live capability.

Terminal
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.

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

FlagPurpose
[dir]App directory (must contain manifest.json). Defaults to the current directory.
--function-id <id>Deploy to an existing app, skipping find-or-create by name.
--runtime <runtime>Runtime for a first-time registration. Default node-25.
--specification <spec>Compute specification for a first-time registration.
--owner <tenant>Tenant to install on. Defaults to the active tenant.
--no-publishSkip the Marketplace publish.
--no-installSkip the install.
--timeout <seconds>How long to wait for the platform build. Default 600.

--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:

Terminal
# 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:

Terminal
revenexx tenants use acme-staging
revenexx deploy app

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

--owner <tenant> does the same for one command without changing the active tenant, which is what a CI job should use:

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

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:

PathHow a version shipsWhen it is right
CLI tarballrevenexx deploy app from a directoryLocal development, a private app you deploy by hand, a CI job that runs the CLI
Git-wiredPush to the connected branchAn app whose repository is the record of what is deployed

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

SymptomUsually
Rejected before the buildA publish-time rule — a vendor/app key, a summary over 255 characters, an undeclared tag, a claimed global name
Build fails on the schemaA notNull column with no default on a populated table, a changed generated expression, or a cross-app foreign key. See Migrations
Build times outRaise --timeout; the default is 600 seconds
Build succeeds, the route still 404sThe install step did not run. Routes are written at install time
Version rejectedversion in manifest.json was already used. Bump it

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.
  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.
  9. Repeat step 6 against production.

Next steps

Was this page helpful?