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
readystatus. - 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
writeaccess. Reading requiresread; deleting a service requiresadmin.
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.