Managed deployments (Publish)

Publish lets project admins deploy supported standard web applications to managed hosting without provisioning their own cloud account. ArxDeck provisions environments, runs builds, exposes branded URLs, and supports staging → production promotion when enabled.

Reach Publish from the project Settings hub (Settings → Publish) — it is not in the project sidebar. All project members can view Publish; project admins configure and deploy.

What Publish provides

• Production and optional staging environments per project
• Manual deploy, retry, suspend, resume, and destroy staging from the dashboard
• Auto-deploy from GitHub when configured (uses the platform GitHub App push webhook — no per-repo webhook setup)
• Secrets management for application environment variables (write-only after save)
• Usage and cost estimates on the Publish page for project admins
• Agent MCP tools to check status and tail logs; configuration changes via propose_deployment_config proposals

Agents wiring a published static site should call get_project_info for each environment's publicUrl (under deployments.environments) together with content API values — do not hard-code hostnames from guesswork or build-time env injection.

Publish validates application contracts (arxdeck.deploy.json, package scripts, Dockerfile detection) and discovers monorepo app roots for admin selection.

Static site publishing

Repositories detected as static sites use a Static site profile instead of the standard Railway web service topology:

• Builds run in an isolated platform-managed environment; artifacts are stored privately and served through a shared static origin
• Validate setup and Repair setup check only static prerequisites (builder environment, artifact storage, static origin, confirmed output directory, gateway route) — not provider project, database, or bucket resources
• Output directory must be confirmed (or edited) before enable or saving configuration
• After a build, Publish shows a bounded build-output inspection: selected directory, candidate directories, file counts, total sizes, and whether each directory contains index.html or index.htm. If the selected directory is empty but candidates exist, you must explicitly choose and confirm a candidate before retrying. A selected directory without a root index entry can still deploy, but Publish warns that the hostname root will not serve an entry page.
• Managed gateway routes for static sites self-heal when inactive: Deploy now and periodic reconciliation attempt activation automatically; Validate setup reports the condition read-only; Repair setup is an explicit retry. Missing uploaded artifacts are reported separately and are recovered by Deploy now or Retry, not Repair setup.
• Secrets are not supported for static sites; static builds do not receive project secrets
• Staging uses the same shared static infrastructure with a separate staging hostname
• Promotion serves the exact staging artifact in production without rebuilding
• If a static deploy stays pending without sandbox acceptance for 10 minutes, Publish labels it stalled. Build logs appear only after the sandbox starts. Project admins can Mark failed or Retry/Deploy now; neither cancels a late sandbox build that may still start in the background.
• Deploy triggers start static and dynamic runs immediately (no cron wait on the happy path). Static builds go live as soon as the control plane finishes uploading artifacts. When the platform static build limit is reached, additional deploys queue in pending until a slot frees.

If static build secrets are introduced in the future, promotion semantics may require a full rebuild or a redesigned secret model.

Setup & configuration

1. Ensure the project has GitHub linked and the repository is reachable for builds (see GitHub).
2. Open Settings → Publish (/projects/[id]/deploy).
3. Run Enable or Validate setup to check topology (web service, optional managed database, storage, gateway routing).
4. Use Repair setup when validation reports fixable gaps (admin confirmation required for destructive database operations).
5. Configure secrets, auto-deploy branch/ref, and staging enablement as needed.
6. Trigger Deploy or rely on auto-deploy after pushes to the configured ref.

Organization admins set deployment limits and budgets at Organization → Deployments.

Superadmins enable the managed deployment platform capability on the deployment operator side — tenant admins only see Publish when the feature is available for their organization.

Technical details

Operator-only infrastructure hostnames, API tokens, and encryption keys are not part of the tenant-facing contract — configure those only through your ArxDeck operator or hosting documentation.

Approved Publish configuration changes are recorded in History with diffs and restore — see Configuration revision history.

Related

• GitHub integration
• MCP integration
• ArxDeck Helper
• Content modules — web_publish capability requirement on some modules