> ## 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.

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.