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

# Overview

> Choosing an installation method and what an installation contains.

<Note>
  This section is for running FaPost on a server. For a checkout to develop
  against, see [Local setup](/contributing/local-setup) instead.

  Three pages here are still missing — configuration reference, observability,
  and troubleshooting. What is written has been followed end to end.
</Note>

How to run FaPost Core on your own infrastructure.

These documents are the source of truth for deployment. Every step is written so
it can be followed by hand; the scripts under `deploy/` automate exactly what is
described here and nothing more. If a script and a document disagree, the
document is right and the script is a bug.

## Choosing a method

| Method                                         | Best when                                                                                                | Trade-off                                                                             |
| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| [Docker Compose](/self-hosting/docker-compose) | You want the shortest path, or your host cannot easily provide PHP 8.4                                   | The whole stack is containers; you manage volumes and images rather than packages     |
| [Bare metal](/self-hosting/bare-metal)         | You already run PHP applications, have package and process management in place, or cannot use containers | You provide PHP 8.4 and its extensions yourself, usually via a third-party repository |

Both are supported and neither is a lesser path. They differ in who provides the
runtime, not in how the application is configured: after either one you run the
same `php artisan install`, and the same services must be running.

Read [Requirements](/self-hosting/requirements) first regardless of method — it lists
what the application needs from a host, including the two things most often
missed: the `pcntl`/`posix` extensions and the `CREATE` privilege on the database.

## The shape of an installation

Whatever the method, a working install has the same parts:

```
             ┌──────────────┐
   HTTPS ───▶│  Web server  │──▶ PHP-FPM ──▶ admin panel, builder, webhook ingress
             └──────────────┘
                                              │
                                              ▼
             ┌──────────────┐          ┌────────────┐
             │  PostgreSQL  │◀────────▶│  Horizon   │──▶ flow execution, messaging
             └──────────────┘          └────────────┘
                    ▲                        ▲
                    │                        │
             ┌──────────────┐          ┌────────────┐
             │  Scheduler   │          │   Redis    │
             └──────────────┘          └────────────┘
                                              ▲
                                              │
   HTTPS ───▶ [ Gateway ] ──────────────────── ┘   (optional, see Webhook gateway)
```

The pieces people forget are Horizon and the scheduler. Without them the site
loads, the admin panel works, and nothing actually happens: messages arrive and
are never answered. See [Services](/self-hosting/services).

## Order of operations

1. Prepare the host — [Requirements](/self-hosting/requirements)
2. Install the runtime — [Docker Compose](/self-hosting/docker-compose) or [bare metal](/self-hosting/bare-metal)
3. Configure the application — `php artisan install`, covered in both guides
4. Start the long-lived services — [Services](/self-hosting/services)
5. Optionally put the Go gateway in front of webhooks — [Webhook gateway](/self-hosting/gateway)
6. Verify — each guide ends with the checks worth running

## Upgrades

See [Upgrading and rollback](/self-hosting/upgrading). The short version: migrations are additive,
tenant schemas migrate separately from the landlord schema, and queue workers
must be restarted after a deploy because they hold the old code in memory.

## Not covered here

* Local development — see [Local setup](/contributing/local-setup)
* Extension development — see the [developer portal](/extending/extension-model)
* High availability and multi-node setups. Nothing prevents them, but nothing has
  been tested or documented, so treat it as unexplored rather than supported.