Skip to main content
Deployments decide which built server artifact receives MCP traffic. A build turns one source revision into an immutable artifact. A deployment applies that artifact and its runtime settings to a target. Each target keeps the same MCP URL as successful deployments replace its current deployment. The production target receives traffic from the server’s stable URL. Pull requests and other tracked branches can have preview targets with their own stable URLs. A successful deployment automatically becomes current for its target. For the build step before deployment, see Build system. For request routing after deployment, see Gateway.
Open a hosted server in Horizon, then select Deployments in the server sidebar. The page shows the stable production URL, current server status, and deployment history across production and preview targets.

​
Deployment model

Production target

The production target’s stable MCP URL routes to its current successful deployment.

Preview target

A pull request or tracked branch can use an isolated target and URL for testing.

Deployment record

Each deployment records its target, status, source revision, build logs, server logs, and creation time.

Current deployment

The latest successful deployment for a target receives traffic at that target’s URL.

​
What starts a deployment

A deployment starts when Horizon has a version and target. It can remain queued while Horizon builds the version. The target determines the URL and whether the deployment uses Production or Preview environment variables.
1

Tracked production branch push

A push to the branch tracked by the production target creates a build. When automatic deployment is enabled for the target, Horizon also creates a deployment. If that deployment succeeds, it becomes Live and the stable production URL routes to it.
2

Pull request update

A pull request update creates a preview build when automatic previews are enabled. When automatic deployment is also enabled for the preview target, Horizon creates a deployment that becomes current for its preview target if it succeeds. Production traffic does not change.
3

API deployment

When automatic deployment is disabled, a tracked push creates a version and build without a deployment. After the version becomes ready, use the API reference to list the project’s versions and create a deployment with the ready version ID and target ID.
4

Redeploy

The current deployment and eligible failed deployments offer Redeploy in their action menus. Redeploy applies the same version with current target settings, including current environment variables. Some older versions must be rebuilt from the same commit with current build settings before Horizon can deploy them again.
5

Rollback

A previous successful deployment’s action menu includes Rollback. Rollback creates a new deployment from that version and its saved runtime settings. When it succeeds, it becomes current for the same target.
A queued or deploying record does not change traffic. If it fails, the target’s previous current deployment continues to serve requests. If a newer deployment replaces it before it starts, Horizon marks it Superseded.

​
Production and preview URLs

Production clients should use the stable server URL shown at the top of the Deployments page. That URL is based on the server name and remains the client configuration target through new deployments, redeploys, and rollbacks. Preview deployments use target-specific URLs. Horizon derives a target slug from the server and branch or pull request, lowercases it, replaces unsupported characters with hyphens, and truncates long values to fit URL and runtime naming limits. Updates to the same preview target keep its URL while changing its current deployment.
A deployment URL is not an access control boundary. Use Horizon authentication, server access, and capability policies for access control.

​
Status labels

A deployment’s label combines its lifecycle status with whether it is current for its target. A Ready label identifies a successful history row. It does not mean that the row is waiting for another action before it can receive traffic. The page also shows a top-level server status based on production deployments. Preview deployment activity does not change this status:
  • Live means the server has a live production deployment.
  • Building means the latest production deployment is queued or running.
  • Failed means the latest production deployment failed and no production deployment is live.
  • Not live means the latest production deployment succeeded, but no production deployment is live.
  • No deployments means Horizon has not created a production deployment for the server yet.

​
Table actions

The table shows Target, Status, Source, and Time for each row. The controls at the end of a row open its build logs and server logs. Server logs become available after deployment starts.

​
Redeploy and rollback

Redeploy and rollback use different configuration points. Redeploy is the way to apply current target settings to the version that already serves traffic. Use it after changing runtime environment variables, authentication mode, or capability policy metadata when the source and built artifact should stay the same. If an environment variable changes build behavior or manifest inspection, create a new build instead. Redeploying an existing artifact cannot change how that artifact was packaged or which capabilities its build discovered. Rollback restores historical behavior. Horizon deploys the selected version with the runtime settings saved for that deployment, including its environment snapshot. The rollback creates a new history row and keeps the target URL the same. A successful deployment can be a rollback source for days when its saved runtime settings are available. Horizon reports Rollback unavailable without starting a deployment when it cannot restore that snapshot. After redeploying or rolling back, reconnect MCP clients that cache manifests or capability lists. Some clients do not refresh tools, resources, or prompts until they reconnect or list capabilities again.

​
What changes when

Deployment behavior depends on which boundary owns the change.

​
Debug deployment behavior

Start from the row that matches the target and source revision you are testing. Use build logs for packaging and manifest inspection. Use server logs for startup and request-time failures after deployment begins.
Check whether the build created a production deployment and whether that deployment succeeded. A preview deployment changes only its preview target. A Ready row is a previous successful deployment, not a pending production change.
Confirm the Live or Preview row has the expected source and manifest. Then reconnect the client or list capabilities again because some clients cache server metadata.
Confirm the target, source branch or pull request, and commit SHA on the deployment row. Each build is tied to the exact commit Horizon resolved when the build started.
Open the row’s build logs when Horizon needed to rebuild an older version. Open server logs when deployment started but the server could not start or handle requests. After correcting the error, select Redeploy if the failed row offers it. If Redeploy is unavailable, create a new build and deployment from your source.
Confirm the selected deployment succeeded within the last days. Some older deployment records do not have the saved runtime settings required for an exact rollback.
The request reached Horizon but did not pass the server’s access settings. Check Authentication, Authorization, server access, personal or service-account keys, and request logs.
Gateway routing succeeded. Check server logs for stdout, stderr, startup failures, handler errors, or upstream failures from the running server.

​
Verify a deployment

Before sharing a target URL, confirm that its current row has the expected source revision and Live, Preview, or Active status. Open its build and server logs, then call representative capabilities through the target URL with the intended authentication and access policy. If the manifest changed, reconnect a client and confirm its refreshed tools, resources, and prompts before depending on the new deployment.

Hosted servers

Understand the hosted-server lifecycle across source, deployments, access, runtime, and observability.

Build system

Learn how Horizon produces deployable artifacts from Python MCP and FastMCP source code.

Environment variables

Configure production and preview environment variables.

Custom domains

Serve the production target from a subdomain you control.