Skip to main content
Orbit doesn’t require any infrastructure beyond what a standard Laravel app needs — a database, a web server, and (if you’re using queued jobs) a process to run them. There’s no separate frontend to deploy or API to stand up.

​
Environment

1

Set production environment variables

In .env (or your platform’s environment variable configuration):
Generate a fresh APP_KEY for production — don’t reuse a development key:
2

Point at a production-grade database

SQLite is fine for local development, but for production, switch to MySQL or PostgreSQL — see Configuration for the variables to set.
3

Configure mail if you plan to add it

Orbit’s notifications are in-app only today (see Notifications), so MAIL_MAILER doesn’t need to be configured for any current feature to work. Leave it as-is unless you’re extending Orbit yourself.

​
Build and deploy

1

Install dependencies without dev tooling

2

Run migrations

Don’t run migrate:fresh in production — it drops all tables first. That command is for local/demo data only.
3

Cache framework configuration

4

Serve the app

Point Nginx or Apache with PHP-FPM at the public/ directory, or run the app’s Docker image directly — see Docker for the container setup, which is suitable for production as well as local development.

​
Running the queue

Session, cache, and queue all default to the database driver. If you rely on queued jobs, run a queue worker under a process supervisor (such as supervisord or systemd) rather than the queue:listen command used in local development, so it restarts automatically:

​
What Orbit doesn’t need

Since Orbit has no public API (see Tech stack) and no broadcasting or mail-driven features in active use, you don’t need to provision a websocket server, a transactional email provider, or API rate limiting for Orbit’s current feature set to work in production.