Skip to main content
When you deploy a workspace from a template, Rigbox often provisions backing services alongside your app. These are infrastructure components like PostgreSQL, Redis, and RabbitMQ that your apps depend on to function. You do not need to install, start, or stop these services manually. Their installed service configuration manages startup. This guide covers how to monitor their health and understand how they connect to your apps.

​
Before you begin

Use the v0.13 CLI and authenticate. Run workspace-management and recipe commands from your local terminal. Commands identified as running inside a workspace require its console terminal or SSH session. Replace example resource IDs with the values returned for your account. Start the target workspace and verify its identity with rig workspace ls.

​
What Are Workspace Services?

Workspace services are infrastructure processes that run inside your workspace and support one or more apps. Common examples include: These services are defined by the template that created your workspace. For example, the Firecrawl template provisions all three.
Not every workspace has backing services. If you created a workspace from the base image or a template that does not define services, the infrastructure bar will not appear.

​
Health Monitoring

Each service has a health command that Rigbox runs periodically to check whether the service is responsive. The results appear in real time on the workspace dashboard.

​
Service Statuses

If a service shows as unhealthy, check the workspace logs for error messages. Most issues are caused by the service running out of memory or disk space.

​
Viewing Services in the Dashboard

Open your workspace detail page. The infrastructure bar appears at the top of the Overview tab, showing each service with its current health status. You can see at a glance whether everything is running smoothly or if something needs attention.

​
App Dependencies

Catalog and template metadata can declare backing-service relationships that the dashboard visualizes. In a multi-app rig.yaml, depends_on controls deployment ordering; it does not by itself inject database credentials or connection URLs. Configure those connections explicitly. For example, a Firecrawl app might depend on PostgreSQL, Redis, and RabbitMQ. If one of those services goes unhealthy, you know immediately which apps are affected.

​
Listing Services via the CLI

Use rig workspace services to retrieve all backing services for a workspace along with their current health status.
The output includes each service’s name, type, and current health status.

​
Managed Automatically

Workspace services follow their installed startup and restart policies. Starting or stopping the workspace also affects those processes. You remain responsible for application configuration, backups, and investigating unhealthy services.
Do not manually stop or modify the systemd units for workspace services. Rigbox manages their lifecycle, and manual changes may cause health checks to report incorrect status.

​
Verify and troubleshoot

Inspect rig workspace ls and rig workspace services --workspace WORKSPACE_ID. For installed apps, check their status and health before opening the returned URL. A created resource or running VM does not by itself prove the application is ready. For failures, start with runtime logs, health checks, or resource exhaustion.

​
Next Steps

  • Workspaces - workspace lifecycle, resizing, and environment variables
  • Firecrawl - a template that uses PostgreSQL, Redis, and RabbitMQ as workspace services
  • Expose Ports & Route Apps - make services accessible at *.rigbox.dev