Skip to content

Set up a service

Choose a source, configure a runtime service or static site, and deploy it.

Create a service inside an environment, choose its source, then deploy it. Runtime services run containers; static sites serve built files. For a command that should run and exit, create a scheduled job.

Before you start

  • Have a product and an environment in ready status.
  • For a runtime repository, provide a Dockerfile. Private repositories need the product’s GitHub connection.
  • For an image source, publish the image publicly. Private registry credentials are not supported.
  • For MCP, use a token scoped to the product with Deployment write access. Reading requires read; deleting a service requires admin.

1. Choose the source

Service
Supported sources
Settings
Runtime
Git repository or public image
Port, replicas, CPU, memory, health checks, variables and optional sleep
Static
Git repository or uploaded archive of built files
Build command, output directory, non-secret build variables, serving options

For a runtime repository, Lepsto looks for a Dockerfile at the repository root or the service’s configured subdirectory. The build context remains the repository root: write COPY paths from that root. There is no automatic framework detection. A missing Dockerfile fails the deploy before building.

For a prebuilt image, supply the registry/repository and tag. An unqualified image name uses Docker Hub; nginx resolves to docker.io/library/nginx. Lepsto pulls the image without building it.

For a static repository, the defaults are npm ci && npm run build and output directory dist. Change them to match your project. An uploaded archive skips the build.

2. Create and configure it

Open Add service on the environment canvas, or call deployment_service_create. Supply the environment, source and a name of up to 80 characters. Its slug is unique in the environment and is the name other services use on the private network.

Select the service’s node to open its panel. Edit name and source under Overview, and runtime settings under Settings. MCP uses deployment_service_update.

Runtime setting
Default
What to check
Container port
8080
Your application must listen on this port. Lepsto injects the same value as PORT.
Replicas
1
Accepted range: 0–50. Zero stops the service.
Readiness check
None
Set an HTTP path starting with / if the application needs time to become ready.
Liveness check
None
Set an HTTP path to detect a process that has stopped responding.
Sleep when idle
Off
Enabling it adds startup delay to the request that wakes the service.

Add variables and secrets before deployment. See scaling for resource limits and probe timings.

3. Deploy

Choose Redeploy on the service panel, or call deployment_service_redeploy. Source, port, resource and variable changes take effect on the next deployment. Replica changes apply without a deployment.

Automatic deployment is on by default. Pushes to the tracked branch rebuild repository services while it is enabled. Set autoDeploy: false with the service update tool to stop push-triggered deployments for runtime or static repository sources; manual and API deployments still work. The UI toggle is currently available for Git runtime sources; change the field through MCP for static sites.

For a runtime service at zero replicas with automatic deployment enabled, the sleep setting determines whether a push starts it.

Static serving options

Both options apply without redeploying:

Option
Behavior
Single-page application
When enabled, missing file paths fall back to root index.html. When disabled, /privacy resolves to privacy/index.html; missing paths use your 404.html with a 404 status.
Markdown for agents
Enabled by default. Clients requesting Markdown receive a Markdown rendering of the page.

You can include a _headers file in the build output using the Cloudflare Pages/Netlify header-file grammar. Static publishing is atomic: requests receive the previous or new version, not a mixture. Static sites have no application container, shell, runtime logs, port, replicas or health checks. Their HTTP metrics are counted per hostname.

Verify it works

Under Service → Deployments, check that the deployment is Active. For an HTTP service, check Networking and wait for the domain to become Active, then open its HTTPS address and test a route your application serves. A hostname being assigned does not mean routing is ready.

For a runtime failure, read the deployment reason and build or runtime logs. Check the declared port and readiness path before redeploying.

Restart or remove a service

Settings → Operations → Restart service, or deployment_service_restart, restarts the same image without a build or new history entry.

Was this page helpful?
Esc

Start typing to search the docs.

↑↓navigate↵select