Skip to content
Console
Menu

Queues

Workflows

Getting Started

Authentication

KV Store

Hosting

What a Service is, what you set on it, and the path from a push to a request.

Today this runs on the management API

Hosting is served through the management API: the Hosting quickstart shows the project, service, deploy and status calls. The collections named on this page (services, source_links, releases, service_rollouts, routes, previews) describe the product's resource model; their commands are not the way to use Hosting at api.sylphx.com.

A Service is one deployable workload. It has a source — a repository, or an image by digest — and everything after that is the platform's: the build, the Release, the rollout, the routes, and the scaling down to zero when nobody is calling.

#The parts you set

FieldTypeWhat it is
sourceServiceSourceWhat the Service runs: a SourceLink repository to build from, or an image by digest to run as-is. Required.
commandstringOverrides the image’s command.
portint32The port the application listens on. The public edge stays 443.
exposureServiceExposureWho can reach the Service. Public by default; internal keeps it off the public edge.
sizeInstanceSizeThe size of each instance: nano, micro, small, standard, large, xlarge or xxlarge. The plan’s size by default.
scalingServiceScalingHow many instances to keep, and how many at most.
healthServiceHealthHow an instance is probed, and how long a new one may take to pass.
envmapPlain environment variables. Nothing secret belongs here.
secret_envmapEnvironment variables bound to Secrets: variable name to Secret name. The value never enters the spec.
regionsstring[]Regions to run in; the project’s home region by default.

#From a push to a request

  1. Source. A SourceLink links the project to one repository through a forge connection. Source is read at an exact commit, with a token narrowed to that repository; a webhook only says that something changed.
  2. Build. The build turns the source into an image — a release candidate identified by its digest.
  3. Release. A Release is the immutable desired state of an environment's workloads. Writing a newer one supersedes the live one; a rollback is a new Release naming older digests.
  4. Rollout. A Rollout moves one Service generation to its Release in waves — a canary Cell, one Cell, one region, all — and no wave advances without fresh recorded evidence.
  5. Routes. A Route sends one exact host and path prefix to one backend. Every destination has its own Route; a wildcard grants no authority.
  6. Previews. A Preview is a pull request's own deployment of the Service, built and torn down by the same Git flow.

#It idles to zero

scaling.min_instances defaults to zero, which means no traffic means no instances: the first request after a quiet spell wakes the Service rather than failing. There is nothing to start, and nothing to shut down. Raise the floor only where a cold start is worse than the idle cost.

Name
orgs/{org}/projects/{project}/envs/{env}/services/{service}
Id
svc_<location><ulid>

A Service's name is a path, and the same path works in the API, the CLI and the console. hosting:read covers the reads; everything that changes the Service needs hosting:write.