Services

A Helipod service is the primary deployment target in your project.

Under the hood, each service runs as a containerized workload with its own deployment history, runtime metrics, configuration, and release controls.

Each service keeps operational state such as:

Changes to service configuration are typically staged and then applied through a deployment action so teams can review rollout impact.

Always-on workloads for APIs, web apps, workers, queues, and similar long-running processes.

Task-based workloads that run on schedule and exit after completion.

From the project canvas:

Helipod supports service creation from:

Open a service tile in the canvas and move to the Settings tab to configure source, runtime commands, variables, scaling, and deployment behavior.

You can attach one of the following source modes:

If a Dockerfile is present in repository mode, Helipod can use it as the build contract.

Connect a repository and select branch/source settings for the service.

When autodeploy is enabled, new commits can trigger build and deployment automatically according to your environment and deployment rules.

Helipod supports standard public registry paths. Example formats:

Private registry deployments require valid registry credentials configured in the service source settings.

For sensitive workloads, keep credentials in service variables and rotate access tokens periodically.

For image-based services, Helipod can detect new image versions and stage updates.

Teams may use:

Because image updates trigger redeployments, plan updates to avoid user-facing disruption.

Typical CLI-based flow:

This path is useful for quick tests, migrations, or workflows where repository integration is not yet configured.

In monorepos, define clear service root paths and build contexts to avoid cross-service dependency confusion.

Services have ephemeral runtime storage by default. If data must survive redeployments, attach persistent volumes.

Use persistent volumes for:

Service-level observability includes:

These signals should be reviewed together when diagnosing rollout regressions.

Teams can enforce approval gates before selected deployments are applied, especially for protected branches or production environments.

This is useful when your process requires release review, change ownership checks, or compliance traceability.

Templates package common service combinations so teams can launch known-good architecture patterns faster.

Use short, descriptive service names and consistent naming conventions to keep project canvases readable as your service count grows.

Delete services from project settings or service controls after confirming there are no active dependencies (domains, volumes, or downstream service references).