> ## Documentation Index
> Fetch the complete documentation index at: https://docs.horizon.prefect.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Plans

> Compare Horizon plan features and understand how plan gates work.

export const extendedObservabilityHistory = "up to 30 days";

export const standardObservabilityHistory = "up to 3 days";

export const enterprisePlan = "Enterprise";

export const developerPlan = "Developer";

export const personalPlan = "Personal";

A Horizon plan applies to an entire organization. It determines which product
capabilities the organization can configure and use. Plans are cumulative:
{developerPlan} includes the capabilities in {personalPlan}, and {enterprisePlan}
includes the capabilities in both lower tiers.

Plan availability and access permissions are separate checks. A plan can make a
feature available to the organization, while [organization and server
roles](/roles) determine which actors can use or manage it.

<Info>
  This page describes standard product availability. Included usage, seat
  quantities, pricing, and contract terms appear in Horizon's <b>Billing</b>
  area and can vary by organization.
</Info>

## Plan tiers

<CardGroup cols={3}>
  <Card title={personalPlan} icon="user">
    For an individual building and operating hosted MCP servers. It includes the
    core build, deployment, gateway, client, and observability workflow.
  </Card>

  <Card title={developerPlan} icon="code">
    For teams operating MCP servers together. It adds organization
    collaboration, durable automation identities, external servers, and more
    control over hosted server networking and authentication.
  </Card>

  <Card title={enterprisePlan} icon="building">
    For organizations that need centralized identity, governed server access,
    curated MCP surfaces, and custom serving domains.
  </Card>
</CardGroup>

Start with {personalPlan} when one person owns the organization and its hosted
servers. Choose {developerPlan} when multiple people need access or when
production automation should use a [service account](/api-keys#create-a-service-account-api-key)
instead of a person's identity. Choose {enterprisePlan} when access must be
managed with custom roles, capability-level policy, or single sign-on.

## Feature availability

A checkmark means the capability is part of the standard plan. A blank cell
means the organization needs a higher plan before it can configure or use that
capability.

| Capability                                                                       | {personalPlan}                 | {developerPlan}                | {enterprisePlan}               |
| -------------------------------------------------------------------------------- | ------------------------------ | ------------------------------ | ------------------------------ |
| Build and deploy [hosted servers](/servers/hosted)                               | <Icon icon="check" />          | <Icon icon="check" />          | <Icon icon="check" />          |
| Connect MCP clients, Playground, and ChatMCP                                     | <Icon icon="check" />          | <Icon icon="check" />          | <Icon icon="check" />          |
| Git-based builds and deployments                                                 | <Icon icon="check" />          | <Icon icon="check" />          | <Icon icon="check" />          |
| Request and session observability                                                | <Icon icon="check" />          | <Icon icon="check" />          | <Icon icon="check" />          |
| Observability history                                                            | {standardObservabilityHistory} | {standardObservabilityHistory} | {extendedObservabilityHistory} |
| Invite [organization members](/members)                                          |                                | <Icon icon="check" />          | <Icon icon="check" />          |
| Create service accounts and service-account keys                                 |                                | <Icon icon="check" />          | <Icon icon="check" />          |
| Register [external servers](/servers/external)                                   |                                | <Icon icon="check" />          | <Icon icon="check" />          |
| Configure [external authentication](/platform/external-authentication)           |                                | <Icon icon="check" />          | <Icon icon="check" />          |
| Disable Horizon authentication for a hosted server                               |                                | <Icon icon="check" />          | <Icon icon="check" />          |
| Use [static egress addresses](/platform/networking#static-egress-addresses)      |                                | <Icon icon="check" />          | <Icon icon="check" />          |
| Publish an [organization MCP registry](/mcp-registry)                            |                                |                                | <Icon icon="check" />          |
| Serve from a [custom domain](/custom-domains)                                    |                                |                                | <Icon icon="check" />          |
| Define [custom server roles](/roles#custom-server-roles)                         |                                |                                | <Icon icon="check" />          |
| Apply [capability-level access](/platform/authorization#capability-level-access) |                                |                                | <Icon icon="check" />          |
| Create [remix servers](/servers/remix)                                           |                                |                                | <Icon icon="check" />          |
| Configure organization [single sign-on](/administration/sso)                     |                                |                                | <Icon icon="check" />          |

The matrix covers generally available plan features. Separately purchased
add-ons appear in the organization's **Billing** area. An add-on enables its own
capability without changing the organization's base plan.

## Feature gates

Horizon checks plan availability at both the dashboard and API boundaries. The
dashboard keeps the surrounding workflow visible and marks unavailable actions
with the plan required to unlock them. API requests for an unavailable feature
return a forbidden response instead of applying the change.

Permissions still apply after the plan check succeeds. For example, an
{enterprisePlan} organization can define custom server roles, but only an actor
with the required organization permission can create or change those roles. A
higher plan never grants an actor additional role permissions by itself.

## Plan changes

The [billing contact](/billing-contact) manages plan changes for the
organization. The effective date shown during checkout or in **Billing**
determines when the new feature set applies. An upgrade unlocks the higher
tier's features when the change becomes effective. A downgrade keeps the
current feature set until its effective date, then applies the lower tier's
availability.

Before a downgrade, review automations, servers, access policies, and identity
settings that depend on the current tier. Requests that require a removed
feature are denied after the lower plan takes effect.

Product feature availability is distinct from technical and usage limits. See
[Limits](/limits) for the runtime, build, request, and configuration boundaries
that apply while a feature is in use.