Rumatadocs
SupportOpen Rumata
Browse documentation

Deployment and release

Open MarkdownOpen JSON

How to settle deployment intent, get approval, build, deploy and publish backends and frontends, and verify a release.

7 min readUpdated Nov 1, 2026

Step-by-step guidance.

Before you start

Settle deployment intent first

Before devising an implementation plan, ask whether the task stays in development or deploys after verification, and wait for the answer. Keep it across Plan and Build and across reconnects. Greetings and explanations are exempt.

  • A production-ready brief or an approved plan does not answer this question. Silence and defaults do not authorize publication.
  • Keep mixed intent per component: one piece can deploy while another stays in development.
  • Development components get no public endpoints or schedules.
  • Private workflow publication for backend integration is an internal runtime step. Explain it, keep access private, and omit cron.
  • Never publish just to test development or to bypass private development access.

Get release approval

  1. Finish development and verification.
  2. Show the actual release: website address, backend services, workflow versions and triggers, and recurring cost.
  3. Wait for approval of those concrete items. Renew approval for material changes.
  4. Publish, then verify each part separately.

Deploy a backend

  1. Call `configureBackendService`, then `runBackendServiceAction`.
  2. For repository source, run `build` and inspect completion before `deploy`. Prebuilt images deploy directly.
  3. Inspect `getBackendService` until the deployment is ready or failed.
  4. Verify a representative operation with `debugBackendRequest`. For a worker, confirm results through its persisted task or status evidence.
  5. Verify state survival when persistence is required.

A saved configuration, a successful build or a running development process is not publication.

Choose a runtime policy

ServicePolicy
HTTP API`sleep_when_idle` by default. A real request wakes it.
Background worker with `port: null``always_on`, or `stop_after_duration` for a fixed run. A worker receives no requests, so `sleep_when_idle` would stop it with nothing to wake it.
Continuous HTTP service`always_on`, when the user requests it.

Publish a frontend

  1. Inspect `getFrontendDeployment` after required backends and workflows are ready.
  2. Call `publishFrontend`. The `workspace` source captures the current or explicitly reviewed retained workspace; `repository` requires the configured factory repository source. Check the source mode and resolved revision before publishing.
  3. Poll the retained deployment status and build logs. A queued response is not a release.
  4. Request the returned public URL and verify the real website.
  5. Report frontend and backend status separately.