Skip to main content
What a host must provide to run FaPost Core. Every deployment method in this section satisfies these requirements differently, but none of them removes one. Verified against composer.json, config/, and the packages actually installed — not against what a typical Laravel application usually needs.

Runtime

PHP 8.4 is the requirement most likely to bite. Debian 12 ships 8.2 and Ubuntu 24.04 ships 8.3, so a bare-metal install needs a third-party repository (sury.org on Debian/Ubuntu, Remi on RHEL-family). Container deployments avoid the question entirely.

PHP extensions

Required — the application will not boot without these:
  • pdo, pdo_pgsql — declared in composer.json
  • redisconfig/database.php defaults REDIS_CLIENT to phpredis. Using predis instead is possible but untested here; if you switch, set REDIS_CLIENT=predis and add the Composer package.
  • mbstring, intl, bcmath — Laravel 12 and Filament
  • gd — image handling in the admin panel
  • zip — Composer and export features
  • json, openssl, tokenizer, xml, ctype, fileinfo, curl — Laravel baseline
Required for queue workers, which is where all flow execution happens:
  • pcntl, posix — Horizon needs both to supervise workers. Missing them is a quiet failure mode: the application serves pages normally while no queued job ever runs, so incoming messages simply never get a reply.

Database privileges

The application creates and migrates a PostgreSQL schema per tenant at runtime, so its database user needs more than the usual read/write grants:
A user without CREATE on the database installs cleanly and then fails when the first tenant is provisioned. Two logical connections are configured, landlord and tenant. They may point at the same PostgreSQL instance and database — the separation is by schema, not by server — but keeping them separate is supported.

Processes that must run

A working installation is more than a web server. These are separate long-lived processes, and the system is silently degraded without them: Queues are separated by purpose (flow.execution, messaging.transactional, messaging.broadcast, messaging.system, scheduled.triggers, sync.external), and Horizon must be configured to consume all of them.

Network

  • Inbound HTTPS for the admin panel and the builder.
  • Inbound HTTPS for webhook delivery, with a certificate that public providers accept. Telegram rejects setWebhook on an invalid certificate, so a self-signed one requires the certificate upload flow instead.
  • Outbound HTTPS to messaging providers and any LLM or RAG endpoint in use.

Resources

There is no benchmark to quote yet, so treat these as starting points rather than sizing guidance:
  • 2 vCPU / 4 GB RAM for a small single-tenant install with a handful of channels.
  • Queue workers dominate memory: each Horizon worker is a full PHP process, and flow execution holds a session while waiting on external calls.
  • PostgreSQL grows with conversation history, which is partitioned — see the conversation logging documentation before planning retention.