Arthur Pariente c9d31930a6

refactor(deploy): leverage Serversideup image conventions, drop custom runtime-mode entrypoint

After re-reading the serversideup/php FrankenPHP image docs, the
canonical way to launch Octane with that image is a Compose `command:`
override — not a custom entrypoint script. The custom script we shipped
reinvented a wheel that Compose gives us for free, and got the port
binding wrong (the image binds 8080/8443 internally, not 80/443).

Image-level changes:

- Delete resources/docker/pick-runtime-mode.sh and the matching
  Dockerfile COPY. Bare `docker run image` now runs Serversideup's
  default FrankenPHP entrypoint (classic mode: one PHP worker per
  request). This is the documented behaviour for anyone consuming the
  image directly via k8s, custom Compose, or Docker Swarm.

compose.deploy.yml changes:

- Drop PHPVMS_OCTANE_ENABLED env (no longer driven by image).
- Add `command:` override on the `app` service that runs
  `php artisan octane:start --server=frankenphp --host=0.0.0.0
  --port=8080 --workers=auto --max-requests=500`. Escape hatch:
  delete the line and recreate the container. Matches upstream docs.
- Fix port mapping to 80:8080 / 443:8443 (image binds unprivileged
  to 8080/8443).
- Add healthcheck using the image-shipped `healthcheck-octane` binary.
- Bump OPcache for Octane: disable timestamp revalidation, raise the
  accelerated-files cap to 20000 to cover Filament + module trees,
  bump interned-strings buffer, enable tracing JIT with a 64M buffer.

CI workflow + README updated to reflect the new escape-hatch
mechanism (remove command:, not set env var).

2026-05-27 19:22:53 -05:00

4.8 KiB

Executable File

Raw Blame History

phpVMS ⁸

phpVMS is a PHP application to run and simulate an airline. It allowed users to register, view flight schedules that you create, and file flight reports, built on the Laravel framework. The latest documentation, with installation instructions is available on the phpVMS documentation site.

Installation

A full distribution, with all the composer dependencies, is available at this GitHub Releases link.

Requirements

PHP 8.3+, extensions:
- cURL
- JSON
- fileinfo
- mbstring
- openssl
- pdo
- tokenizer
- intl
- zip
Database:
- MySQL 8.0+ (or MySQL variant, including MariaDB 10.2+ and Percona 8.0+)

View more details on requirements

Installer

Upload to your server
Visit the site, and follow the link to the installer

View installation details

Production Deployment with Docker

The reference production stack is compose.deploy.yml. It runs the official phpVMS image (built from the repo Dockerfile, based on serversideup/php:8.5-frankenphp) with Laravel Octane worker mode enabled, plus MariaDB and Redis. No separate web-server sidecar is needed — FrankenPHP serves HTTP/HTTPS directly.

docker compose -f compose.deploy.yml up -d

Octane worker mode

The image itself ships with serversideup's default classic FrankenPHP entry point (one PHP worker per request). compose.deploy.yml opts into Laravel Octane worker mode via a command: override on the app service — the pattern documented upstream.

To fall back to classic FrankenPHP + PHP-worker mode (matches the prior PHP-FPM request semantics — slower per request but bulletproof if a worker-mode bug hits), delete the command: line from the app service and recreate the container:

services:
  app:
    # command: [...octane:start...]   # remove this line

Under worker mode, KvpService (the JSON-backed key/value store used for non-hot settings) is eventually consistent: writes from one worker propagate to other workers on their next read of the same key. If your deployment requires strong consistency for KVP, run with --workers=1 or remove the command: override.

Module authors: under Octane the framework stays booted across requests, so avoid per-request data in singleton-bound services, static array accumulators, and boot()-time toggles without a matching per-request reset. See app/Http/Middleware/DisableActivityLoggingByDefault.php for the pattern used to keep activity logging request-scoped.

Development Environment with Docker

A full development environment can be brought up using Docker and Laravel Sail, without having to install composer/npm locally

make docker-test

# **OR** with docker directly

docker run --rm \
    -u "$(id -u):$(id -g)" \
    -v "$(pwd):/var/www/html" \
    -w /var/www/html \
    laravelsail/php84-composer:latest \
    composer install --ignore-platform-reqs

# Then you can start sail
./vendor/bin/sail up

Then go to http://localhost.

Instead of repeatedly typing vendor/bin/sail to execute Sail commands, you may wish to configure a shell alias that allows you to execute Sail's commands more easily:

alias sail='[ -f sail ] && sh sail || sh vendor/bin/sail'

Then you can execute php, artisan, composer, npm, etc. commands using the sail prefix:

# PHP commands within Laravel Sail...
sail php --version

# Artisan commands within Laravel Sail...
sail artisan about

# Composer commands within Laravel Sail...
sail composer install

# NPM commands within Laravel Sail...
sail npm run dev

To interact with databases (MariaDB, Redis...), please refer to the Laravel Sail documentation

Building JS/CSS assets

Yarn is required, run:

make build-assets

This will build all the assets according to the webpack file.

Laravel Boost

If you want to use AI agents for your development workflow, please ensure you install Laravel Boost by running the following command:

php artisan boost:install

Contributors

Thank you to everyone who've contributed to phpVMS!

4.8 KiB Executable File Raw Blame History

phpVMS 8