Service types: web, private, static, cron and workers

Web service

A web service is anything that needs to be reachable from the internet — your backend API, a full-stack app, a webhook endpoint. When you deploy a web service, it gets a public URL with HTTPS included. You can also set up a custom domain whenever you want. Deploy from a Git repo or a container image, and we take care of builds, TLS certificates, and routing.

Public URL & domains

When you create a web service, Partiri assigns it a public URL on an auto-generated subdomain, served over HTTPS with TLS handled for you. You can also point a custom domain at it. Requests reach your container through the platform's ingress.

Source, build & deploy

Deploy from a Git repository or a pre-built container image. With a repository you set a build command and a run command, plus an optional pre-deploy command (for example database migrations); with an image there is no build step. You can also set a health check path that the platform polls before routing traffic to a new release. Repository-based services (cron jobs aside) get a git webhook, so when the auto-deploy setting is on, a push to the configured branch triggers a new deploy — see Webhooks under Configuration for the details.

Scaling & infrastructure

Choose a pod size (CPU and memory) and a primary region; both can be changed later. A web service can also run in additional replica regions, and can attach a persistent disk when it needs to keep data across restarts and redeploys.

Private Service

Private services run inside the platform but aren't exposed to the public internet. There's no public URL, no ingress — they only talk to your other services. This is the right choice for internal APIs, background workers, job processors, or any supporting service that doesn't need to face the outside world. Your other services can reach them through simple private connectivity.

Internal connectivity

A private service is internal-only: Partiri assigns no public URL, custom domain, or ingress for it. Your other services reach it through an internal service-discovery address inside the platform. Use it for internal APIs, background workers, and anything that should never be exposed to the internet.

Source, build & deploy

Like a web service: deploy from a Git repository or a container image, with a build command, a run command, an optional pre-deploy command, and a health check path. The only difference is that no public address is assigned.

Scaling & infrastructure

Pick a pod size and a primary region, changeable later. Private services can run in additional replica regions and can attach a persistent disk for stateful workloads.

Static website

Static websites are for SPAs, documentation sites, landing pages, and anything that is just static assets — HTML, CSS, JavaScript, and images. Partiri builds your project from its Git repository and serves the output directly. You get a public URL with HTTPS, and you can add a custom domain.

Build & output

A static site builds from a Git repository — container images are not an option for this type. Set the publish directory (the build path) that holds your generated files, and add a build command if your site needs a build step. There is no run command: Partiri serves the built files directly, so the runtime is fixed to static.

URL & domains

A static site gets a public URL on an auto-generated subdomain over HTTPS, and you can point a custom domain at it.

Constraints

Static sites deploy from a Git repository only (no container images). They have no run command, no health check, and no persistent storage — the published files are static.

Cron Job

A Cron Job runs a containerised workload on a schedule or as a one-shot task. When the scheduler is disabled the service runs once per deploy (a Kubernetes Job); when enabled it runs on a repeating cron schedule (a Kubernetes CronJob). Typical use cases: data pipelines, database backups, report generation, and cleanup tasks.

Scheduling

Schedules use standard 5-field cron syntax (minute hour day month weekday). The dashboard provides a quick builder for common intervals (every N minutes, hours, or days) and a live 24-hour preview that shows when the next runs will occur. Each cron job has an IANA timezone field so schedules follow a consistent wall-clock time regardless of server timezone.

Concurrency policy

The concurrency policy controls what happens when a new run is triggered while a previous run is still active. Forbid skips the new run if one is already running. Allow lets multiple runs overlap. Replace cancels the current run and starts a new one.

Execution controls

Max runtime (required) sets the hard deadline in seconds — the job is terminated if it exceeds this limit. Backoff limit controls how many times a failed run is retried before the job is marked as failed (default: 3). TTL after finished defines how long the completed job object is kept before it is deleted (default: 3600 s). Successful and failed history limits cap how many past runs are retained for inspection.

Constraints

Cron Jobs cannot use persistent storage (volumes bind to long-running services). Replica regions are not supported — cron jobs run in the primary region only. Custom domains are not available for cron job services.

Worker

A worker is a long-running background process with no public network exposure — no public URL, no ingress, and no exposed port. Use it for queue consumers, background job processors, and any task that needs to run continuously without being reachable from outside the platform.

No public network

A worker has no public URL, custom domain, ingress, or exposed port, and there's no health check path to configure — it can't be reached directly. It can still reach other services and the internet outbound, which is all a background process like a queue consumer needs.

Source, build & deploy

Deploy from a Git repository with a run command, or from a pre-built container image — a worker needs a runnable process either way. Auto-deploy on push works the same as other services, using a Git webhook.

Scaling & billing

Pick a pod size and a primary region, changeable later. Workers can run in additional replica regions and can attach a persistent disk for stateful workloads, and are billed at a flat monthly rate per replica, the same as a private service.