> ## Documentation Index
> Fetch the complete documentation index at: https://frp.xdr.ooo/llms.txt
> Use this file to discover all available pages before exploring further.

# What is FRP Auto Deploy?

> Understand the problem FRP Auto Deploy solves and the operating model.

# What is FRP Auto Deploy?

FRP Auto Deploy is a **lightweight deployment and operations layer for official FRP**. It is built for small remote-access environments where a few systems to a few dozen systems need to be reached safely from outside private networks.

<Note>
  **FRP** is the tunnel engine. **FRP Auto Deploy** is the installation, enrollment, identity, service, port, lifecycle, backup, diagnostics, and operator experience around it.
</Note>

## The problem it solves

Without a reverse-tunnel approach, remote support often becomes a chain of infrastructure requests:

```mermaid theme={null}
flowchart LR
    E[Support engineer] --> V[Request VPN access]
    V --> F[Request firewall/NAT change]
    F --> B[Find bastion / internal path]
    B --> H[Reach private server]
```

For temporary support, labs, partners, branches, and small infrastructure, that process can be much heavier than the actual technical task.

## The operating model

Install the public server once. Remote clients enroll and initiate outbound tunnels toward it.

```mermaid theme={null}
flowchart LR
    O[Operator]
    S[FRP Auto Deploy server\npublic entry point]
    C[Remote client\nbehind NAT/firewall]
    LOCAL[Local services\n127.0.0.1:*]
    LAN[Other LAN hosts\n10.x / 172.16-31.x / 192.168.x]

    C -->|outbound FRP control| S
    O -->|public service port| S
    S -->|service traffic| C
    C --> LOCAL
    C --> LAN
```

A client can publish its own services or act as a small gateway for services on other LAN hosts that it can reach.

## Who is it for?

<CardGroup cols={2}>
  <Card title="System administrators" icon="server">
    Reach remote Linux systems without building a full VPN or RMM stack.
  </Card>

  <Card title="Technical support engineers" icon="headset">
    Give customers or partners a controlled one-command onboarding path.
  </Card>

  <Card title="Lab / partner operators" icon="flask">
    Publish a few services from private networks through one controlled public entry point.
  </Card>

  <Card title="Small infrastructure teams" icon="network-wired">
    Manage a few to a few dozen systems with stable identities, ports, and a CLI.
  </Card>
</CardGroup>

## What the product manages

```mermaid theme={null}
flowchart TB
    FRP[Official FRP\nTunnel engine]
    AD[FRP Auto Deploy]
    AD --> I[Install / update]
    AD --> E[Enrollment / trust]
    AD --> ID[CLIENT ID / metadata]
    AD --> SV[Service definitions]
    AD --> PP[Persistent public ports]
    AD --> CLI[frpctl operations]
    AD --> DR[Backup / restore / doctor]
    FRP --> AD
```

## What it intentionally does not manage

* cloud security groups
* external firewalls or NAT/DNAT rules
* UFW, firewalld, or iptables policy
* DNS provider records
* operating-system accounts, passwords, or SSH keys
* application authentication
* application TLS certificates

Keeping those boundaries explicit makes the product smaller and easier to reason about.

## Supported service model

The stable core publishes **TCP** services:

* SSH
* HTTP
* HTTPS passthrough
* Custom TCP

Each service gets a stable Service ID and a persistent public-port reservation.

## Recommended reading order

1. [Concepts & Mental Model](/getting-started/concepts) — terminology and diagrams
2. [Quick Start](/getting-started/quickstart) — first working connection
3. [Publishing Services](/guides/services) — SSH/web/custom/LAN examples
4. [frpctl Guide](/frpctl/overview) — everyday operation
5. [Architecture](/reference/architecture) — expert internals