Getting Started

Understanding service types

6 min readUpdated April 2026

StackBlaze projects can contain four kinds of service: Web services, Workers, Cron jobs, and Databases. Each maps to a different Kubernetes workload type and has different capabilities around public exposure, scaling, and persistence.

Picking the right type upfront is important, it cannot be changed later without recreating the service. The diagram below shows how all four types typically connect in a real project.

Service topology

queueTCP:5432
Web Service
public HTTPS

Deployment + Ingress

Worker
private

Deployment only

Cron Job
0 2 * * *

CronJob → Job → Pod

Database
StatefulSet + PVC

postgres.internal

Comparison

Web Service

Deployment + Service + Ingress

Public URLYes, HTTPS endpoint
KubernetesDeployment + Service + Ingress
ReplicasConfigurable (default 1)
AutoscalingHPA available
Use whenYou need to serve HTTP traffic

Worker

Deployment (no Ingress)

Public URLNo
KubernetesDeployment only
ReplicasConfigurable
AutoscalingHPA or KEDA
Use whenProcessing queues or background jobs

Cron Job

CronJob

Public URLNo
KubernetesCronJob → Job → Pod
ScheduleStandard cron expression
ConcurrencyForbid / Allow / Replace
Use whenScheduled periodic tasks

Database

StatefulSet + PVC + Service

Public URLNo, internal DNS only
KubernetesStatefulSet + PVC + Service
StoragePersistentVolumeClaim
BackupsDaily snapshots (PITR optional)
Use whenYou need managed persistent storage

Working with service types

01

Choose your service type when adding a service

In the dashboard click "New service". StackBlaze asks you to pick a type first. This determines the Kubernetes workload kind and whether a public Ingress is created.

02

Configure the type-specific settings

Web services have a health-check path and replica count. Cron jobs have a schedule expression and concurrency policy. Workers have queue connection settings. Databases have a storage size and version selector.

03

Connect services via the internal network

Every service in a project gets a stable internal DNS hostname: <service-name>.internal. A web service can call a worker via http://worker.internal:8080 without going through the public internet, all traffic stays within the Kubernetes cluster.

04

Change type by creating a new service

Service types cannot be changed after creation because they map to fundamentally different Kubernetes resources. If you need to switch from a worker to a web service, create a new service from the same repo and delete the old one.