# Services

Build, run, and manage the backend services that power your application—all in one place.

Source: https://docs.rumata.dev/guides/system-explorer-services
Reviewed: 2026-09-29

<a id="build-and-connect"></a>

## Choose a source and connect your frontend

To create a service, choose a **Docker image** from Docker Hub, build from a **Dockerfile**, or use a **Native runtime** for Node.js or Python. Follow [Build and connect backend services](https://docs.rumata.dev/guides/backends) for the source fields, build commands, and frontend bindings in `rumata.backends.json`. For service-to-workflow calls, see [Call workflows with API keys](https://docs.rumata.dev/guides/api-keys).

<a id="introduction"></a>

## About Services

Rumata's **Services** section gives you control over the APIs, containers, background workers, and development services your application needs.

You can monitor performance, configure resources, manage deployment settings, and troubleshoot issues without leaving your workspace.

Whether your services were created with Rumata's AI agent or configured manually, you can inspect and manage them through System Explorer.

<a id="before-you-start"></a>

## Before you start

Open your factory workspace and navigate to **System Explorer → Build → Services**.

Here, you'll find the services available in your factory, along with their current status and configuration.

<a id="open"></a>

## 1. Find and explore your services

The **Services** section brings together the backend services associated with your application.

A service might handle API requests, process background tasks, or run custom application logic.

Find a service

1. Open **System Explorer → Build → Services**.
2. Use **Search services** to find a service by name.
3. Filter the list using **All**, **Running**, or **Not running**.
4. Check the service card to see its runtime and publication status.
5. Click a service to open its details.

**Understanding service status**

- **Running:** The service's computing process is active.
- **Not running:** The service's computing process isn't currently active.
- **Published:** The service has been made available through a deployment, subject to its endpoint configuration and access rules.

> **Good to know**
> A service can be running without being published. Running a service does not automatically make it accessible to external users.

<a id="monitor"></a>

## 2. Monitor performance and storage

The **Storage & usage** section helps you understand how your service uses computing resources.

Check your service's resource usage

1. Open a service and select **Storage & usage**.
2. Review **CPU usage** to see how much processing power the service is using.
3. Check **Memory in use** to understand its current memory consumption.
4. Compare usage with the allocated limits and available replica count.
5. Click **Refresh** to request updated measurements. Check the observation timestamp to see when the data was collected.

Understand persistent storage

Some services need to save information that remains available even when the service stops or restarts.

Rumata supports optional **persistent disks** for services that require durable storage.

Here's the difference:

- **Temporary container storage:** Files stored only inside the container may be lost when the container is replaced.
- **Persistent disk:** Stores information separately from the running compute process, allowing the data to remain when compute stops or the service is unpublished.

**Important things to know:**

- Persistent disks retain their allocated storage independently of whether the service is running.
- Automatic backups of persistent disks are not included.
- Private development processes do not mount the production persistent disk.

Check your result

You should be able to see your service's current computing resource usage, allocated limits, and any configured persistent storage.

![Service details show running state, resource usage, and storage options.](https://docs.rumata.dev/media/system-explorer/services.png)

Service details show running state, resource usage, and storage options. Illustrative interface reference; your resources and values may differ.

<a id="development"></a>

## 3. Explore private development

Rumata lets you work on a service in a private development environment before making changes available to users.

This allows you to test functionality and review changes without immediately affecting the published service.

Check your development environment

1. Open your service and select **Development**.
2. Check whether private development is currently running.
3. Select **Test private preview** to verify the development endpoint.
4. If changes aren't appearing, review the configured development command.

**How it works**

Private development uses the working files on your development machine.

Automatic updates depend on whether your development command supports watching for file changes, commonly called *live reload*.

Selecting **Stop development** stops the private development process.

> **Good to know**
> Your private development environment is separate from your published service. Testing changes privately doesn't automatically deploy them to production.

<a id="settings"></a>

## 4. Configure your service

The **Settings** section lets you control how your service runs, communicates, and is deployed.

Review your service settings

1. Open the service and select **Settings**.
2. Review the **Service name** and **Service type**.
3. Check the **HTTP port** used by your application, when applicable.
4. Review the **Runtime policy** to determine when the service should run.
5. Check **Endpoint access** to control how the service can be reached.
6. Explore **Environment variables**, **Advanced settings**, **Private development**, and **Source configuration** when needed.
7. Click **Save settings** after reviewing your changes.

Choose how your service runs

Rumata offers different runtime policies depending on your service's needs:

- **Automatic shutdown:** Allows compute to shut down automatically under its configured policy.
- **Sleep when idle:** Allows the service to enter a sleeping state when it isn't being used.
- **Always on:** Configures the service to remain running, subject to available resources and account allowances.

These options give you flexibility to balance availability and resource consumption.

> **Important**
> Saving settings doesn't immediately apply them to the live deployment. Updated deployment settings take effect on the next deployment.

When you're ready, select **Deploy** to apply the intended configuration.

Resource limits or exhausted allowances may still stop compute, even when an always-on policy is selected.

<a id="endpoints"></a>

## 5. Manage your API endpoints and access

Your services may need to communicate with your application, other services, or external systems.

Rumata provides endpoint configuration and access controls to help you determine how those connections work.

Explore your endpoints

1. Open your service.
2. Find **API endpoints** to review its available endpoint information.
3. Go to **Settings → Endpoint access** to review how the endpoint can be reached.
4. Select the appropriate access configuration for your intended users or integrations.
5. Save your settings and deploy when ready to apply changes.

Understand endpoint access options

**Rumata permissions**

Access is controlled through Rumata's permission system, allowing requests to be governed by the platform's configured access rules.

**Direct HTTPS · application authentication**

The service endpoint becomes publicly reachable over HTTPS, while your application is responsible for authenticating users and enforcing authorization.

This is useful when your application needs to manage its own authentication or receive requests from external systems.

> **Important**
> Direct HTTPS doesn't automatically make an endpoint secure. Your application must implement the appropriate authentication, authorization, and validation.

Rumata continues to control the service's configuration, deployment, secrets, and deletion.

Test your endpoint

After configuring access, test the endpoint using the type of caller it is intended to serve.

For example:

- An authenticated application user.
- An authorized external integration.
- A public visitor, if public access is intended.

Check your result

Your endpoint should respond as expected, and users or integrations should only be able to perform the actions they're authorized to access.

A service status indicator alone doesn't confirm that its access controls work correctly.

<a id="activity"></a>

## 6. Review service activity and troubleshoot issues

If your service isn't behaving as expected, Rumata provides operation history and build logs to help you investigate.

Check recent operations

1. Open your service and select **Activity**.
2. Review **Recent operations** to find previous build or deployment attempts.
3. Identify the relevant operation using its timestamp and status.
4. Click **View build logs** when available to investigate build-related issues.
5. Review the reported error and correct the underlying issue before retrying.

You can also ask Rumata's AI agent to help investigate an error or suggest the necessary changes.

## Related guides

- [Code and development machines](https://docs.rumata.dev/guides/development)