Your first deploy

Deploy a runtime service from a GitHub repository, then open its generated HTTPS address. This tutorial uses a repository with a working Dockerfile; Lepsto does not automatically detect your framework for runtime builds.

Prerequisites

Lepsto access, a product, and a ready production deployment environment.
A GitHub repository with a Dockerfile at its root and a main branch. The container must serve HTTP on port 8080, or you must set its actual port when creating the service.
For a private repository, a GitHub integration attached to the product and covering that repository.
Permission to create a service and read environments, services, and deployments. For MCP, a product-scoped token must allow deployment_environment_list, deployment_service_create, deployment_service_redeploy, deployment_service_get, deployment_deployment_list, and deployment_deployment_get.

The example uses the product Acme and service web. Replace the product name and repository with your own. For prebuilt static files, use the static-service guide.

Step 1 — Select the environment

In the web app, select Acme and open its production deployment environment.

The agent uses deployment_environment_list and retains its returned environment ID. If the environment is still being prepared or has failed, resolve its status before creating the service.

Step 2 — Create the service

Choose Add service on the environment canvas, select GitHub repository, and choose your repository and main branch. Name the service web and set its container port if it is not 8080.

The agent calls deployment_service_create with environmentId, name, and a source of type git with branch. Private repositories use the attached GitHub connection and repository name. The tool’s publicDomain option defaults to true, enabling a generated hostname under lepsto.run. Setting it to false removes the generated hostname’s route; custom domains remain.

The Dockerfile controls the build. In a monorepo, its location can be a service subdirectory, but Docker COPY paths still use the repository root as the build context. A missing Dockerfile fails the deployment.

Step 3 — Check the deployment

Ask the agent to list deployments for web with deployment_deployment_list, then read the newest one with deployment_deployment_get. If none is running, ask it to start a deployment with deployment_service_redeploy.

Wait for Active. Building and Deploying are still in progress; Failed includes a reason to investigate. A runtime build has a 30-minute deadline, followed by up to five minutes to become ready. Do not start another deployment while one is running.

Step 4 — Verify it works

Ask the agent to read the service with deployment_service_get and return its generated address. Confirm the domain is Active before opening it yourself and checking the same page.

An Active deployment, an Active domain, and the expected page at that address confirm this first deploy. If the address responds incorrectly, check the application’s port, build output, and deployment logs.

When automatic deployment is enabled, pushes to the tracked branch redeploy this service. Before adding secrets or another environment, read Variables and Environments.

Was this page helpful?