Services

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 for the source fields, build commands, and frontend bindings in `rumata.backends.json`. For service-to-workflow calls, see Call workflows with API keys.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.