The administration hub your app uses to
look under the hood — inspect logs, run commands, manage
queues, schedule jobs, watch performance, and keep tabs on
deployments, all from one signed-in, permission-protected
web console at /hub.
ForgeHub is a collection of admin screens that group the everyday operations of a Forge app in one place. Instead of reaching for the terminal or digging through files, an administrator gets a browser-based console that reads and operates on the same state your app and its other capabilities write.
The hub is deliberately modular. Each section tackles a single concern, and many are backed by another capability when that capability is installed — the queue screens inspect ForgeEvents' queues and workers, the deployment screens drive ForgeDeployment, and the debugbar screen shows ForgeDebugBar's latest capture. When a backing capability isn't installed, that section simply isn't available, rather than erroring out.
Framing: this is an administration console your app puts on top of its own capabilities — not framework machinery. You install the pieces you use, protect the console behind your auth, and ForgeHub assembles the screens that make sense for your app.
php forge.php package:install-module --module=forge-hubThe hub is a web application of its own, so it needs a router and authentication to expose its screens. Many sections bring their own capabilities with them — the deeper you want the hub to reach, the more of the surrounding tooling you'll install alongside it.
Every hub screen sits behind your app's authentication.
A visitor who isn't signed in is sent to log in, and a
signed-in user whose account isn't allowed through is
turned away. Most sections also require the
ADMIN role and check the
HUB_PERMISSIONS permission on each
endpoint.
This means the hub is only as open as your auth and role setup permit. You decide which users carry the admin role and the hub permission — the console itself won't bypass your rules.
The hub opens on a dashboard that summarizes the app at a glance: PHP and kernel versions, how many modules are installed, how many hub screens are available, the count of cached keys, and log file details. If the event system is installed, it also shows live queue totals (total, pending, failed).
A system-information panel rounds it out with server time, timezone, memory limit, and max execution time — the sort of quick facts you reach for when something looks off.
The commands screen is a terminal in the browser. It lists every CLI command your app knows, grouped by category, shows each command's declared arguments, and lets you run a command and watch its output stream back in real time.
Not everything is fair game. Dangerous and long-running operations are filtered out before they're shown, so a stray click can't take your app down from the console.
Three screens handle the everyday inspection work:
The logs screen reads your app's
storage/logs files directly and
parses each line into a structured entry —
timestamp, level, message, and any context it
carries. You can filter by level or module
using quick chips, or search by text and filter
by date or a request fingerprint, then open any
entry to see its full detail. No separate
logging capability is required — the hub
understands the log format your app already
writes.
A read-only catalog of the modules your app has installed — name, version, description, author, license, type, and the hub screens each one contributes. Handy for seeing at a glance what's powering your app.
Shows which cache driver and keys are live, the number of cached files and their total size, and the tags they're grouped under. From here you can clear everything, clear only entries that expired beyond a window you choose, or clear just one tag — commands, routes, views, config, and so on.
When the event system is installed, the hub gives you hands-on control over the background work your app runs:
A live, sortable view of the jobs waiting in your queues, with totals for pending, processing, and failed work. You can retry a failed job, delete a job you don't want, or trigger one to run, and you can select multiple rows to retry or delete in bulk. Filters, search, and pagination keep large queues manageable.
Create, edit, and delete background workers — each with a name, the queues it consumes, and how many processes it runs. Start and stop workers from the console, and view or clear a worker's recent output without logging into the server.
If the event system isn't installed, neither screen is available — there's nothing to inspect without it.
Manage the scheduled jobs your app runs. Create a job from a forge command or a script command, choose a simple or a full cron-expression schedule, enable or disable it, and run it manually to see it work. Each job captures its output, which you can view or clear. Enabled jobs are installed into your system's crontab automatically.
A live snapshot of the server the app runs on: CPU load, PHP memory usage and limits plus OS-level memory on Linux, macOS, or Windows, disk usage on your root and storage partitions, and system details like uptime. Refresh to see the numbers move.
The observability screens turn the kernel's trace sampling into something you can browse. When enabled, each request is measured — its duration, database queries, errors, and slow paths — and a sample of traces is kept for inspection.
Sampling is under your control. The default is adaptive — always keep error and slow traces, and keep a random fraction of the rest. You can force everything, or set the slow thresholds that decide what counts as worth sampling. Stored traces are pruned after a retention window (seven days by default) so the table doesn't grow forever.
This section is off by default. You turn it on with an environment flag, and it stores traces in your database — both are up to your app's configuration.
When the deployment capability is installed, the hub becomes a control center for shipping your app. It shows the current deployment configuration and recent logs, and lets an administrator:
Everything happens against the same config and secrets your deployment capability already manages, so the console is a face on what you'd otherwise run from the CLI.
Two screens round out the shell for whoever is signed in:
When the app's auth profile is present, these screens keep personal details close at hand without leaving the console.
ForgeHub is meant to be consumed as a console, not
called from your business logic. But it's built to be
extended: a module declares a
#[HubItem] — a label, a route, an icon, and
an ordering — and the hub picks it up and lists it in
its navigation. That's how ForgeDebugBar adds its own
debug bar screen to the hub without ForgeHub knowing
about it in advance.
The hub's navigation is assembled from these declarations, so the console grows with your app. There are two groupings it respects:
If you want to add a custom admin screen for your own feature, you give it a route, protect it with the hub's permission rules, and declare it as a hub item — it shows up alongside the built-ins.