Mission Control Laravel Laravel Package

Getting Started

Treat this as glue code, not a framework. The entire surface area is a service provider, a published config file, and (usually) one or two artisan commands or scheduled jobs that report app health into a Mission Control dashboard. Budget an hour of source reading before you run an installer.

1. Read the source in this order: composer.json (Laravel/PHP constraints and transitive Grafite siblings), src/*ServiceProvider.php (what gets registered, which routes/commands/schedules exist, whether registration is unconditional), then config/*.php (exact env keys and defaults). At 2 stars there is no tutorial corpus to substitute for this.

2. Install into a disposable scaffold first, not your real app:

   composer require grafite/mission-control-laravel
   php artisan vendor:publish --provider="Grafite\MissionControl\MissionControlServiceProvider"
   

   If the provider is not auto-discovered, register it in bootstrap/providers.php (Laravel 11+) or config/app.php.

3. Configure via .env, never by editing the published config. Confirm the real key names from the config file rather than guessing — small packages often use inconsistent prefixes:

   MISSION_CONTROL_URL=https://mission-control.example.com
   MISSION_CONTROL_TOKEN=xxxxxxxx
   MISSION_CONTROL_ENABLED=true
   

4. Verify the wiring is actually live before trusting it: php artisan route:list | grep -i mission, php artisan list | grep -i mission, and php artisan config:show <published-file>. Three commands tell you whether routes were mounted, commands were registered, and your env is being read.

5. First real use case: register the app in Mission Control, drop in the token, then trigger whatever the package exposes (a health command, a ping, or a dashboard pull). Confirm the app shows as connected in the UI before you build anything on top of it. The connection handshake is the whole value proposition — if it does not work, stop there.

If the package ships a scheduled reporter, wire it in routes/console.php (Laravel 11+) or app/Console/Kernel.php:

Schedule::command('mission-control:ping')->everyFiveMinutes()->withoutOverlapping();

Implementation Patterns

Environment-gated reporting. The single most important pattern: local and CI must never phone home. Put the switch in config, read it from env, and then verify the package actually respects it — small packages frequently register routes or schedule entries unconditionally regardless of an enabled flag:

// config/mission-control.php — shape is typical, confirm against the real file
'enabled' => env('MISSION_CONTROL_ENABLED', false),
'url'     => env('MISSION_CONTROL_URL'),
'token'   => env('MISSION_CONTROL_TOKEN'),

One token per environment. Staging and production must be separately identifiable in the dashboard, or every incident triage starts with "which app was that?" Generate distinct tokens per environment and per app instance; never share a token across a fleet.

Register the schedule in version control, not by hand. Keep the Schedule::command(...) line in routes/console.php so it survives deployments, and always pair it with withoutOverlapping() — a reporter that hangs and stacks up is worse than no reporter.

Wrap outbound calls in your own job. Do not let the package's HTTP call sit on a request path or inside a critical queue worker. Put the reporting behind your own queued job with a short timeout and ->onFailure(fn () => null) semantics, so a Mission Control outage degrades observability rather than your application:

// app/Jobs/ReportHealthToMissionControl.php
public function handle(): void
{
    try {
        Artisan::call('mission-control:ping');
    } catch (\Throwable $e) {
        report($e); // never rethrow — telemetry must not break the app
    }
}

Scope the pilot to one service. Given zero dependents, do not roll this across several apps simultaneously. Pick one internal-facing or staging service, run it for a bounded period, and measure whether the dashboard actually answers questions your team asks. Spreading it widens the blast radius of a package that has no downstream users finding its bugs for you.

Keep an exit hatch wired in from day one. Because the integration is thin, it is also easy to remove — but only if you have not let the package own anything structural. Before adopting, confirm it does not publish migrations into your schema or replace your auth. If it does, treat it as a platform decision, not a dependency.

// Feature-flag the whole integration so you can kill it in one config flip
if (config('mission-control.enabled')) {
    Schedule::command('mission-control:ping')->everyFiveMinutes()->withoutOverlapping();
}

Pin exact versions and commit the lockfile. composer require grafite/mission-control-laravel:1.2.3 — not ^1.2. Then record the pin and the reason in your dependency notes, with a review date, because this constraint will eventually block a framework upgrade.

Gotchas and Tips

Version compatibility is the go/no-go gate. This package's vintage and near-zero recent signal suggest a Laravel 5.8–7.x target band. If your app is on Laravel 10/11 with PHP 8.2+, a two-hour scaffold spike will settle it definitively — do that before any estimation. No amount of integration effort fixes an incompatible constraint.

enabled => false may still register routes. Small packages often bind routes and schedules in register() or boot() without checking config. After setting the flag to false, re-run php artisan route:list and confirm nothing was mounted. If something was, you need a provider-level guard or a conditional registration in your own AppServiceProvider.

Check whether it publishes migrations. If vendor:publish offers a --tag=migrations option, read every migration before running it. Published migrations that create or alter a users table will collide with your schema, and the failure surfaces late — usually mid-feature-cycle, as duplicate identity.

Transitive footprint is the real dependency. This is likely a meta/integration layer pulling sibling Grafite packages plus compiled frontend assets. Run composer why grafite/mission-control-laravel and composer show --tree and enumerate everything it drags in before you commit. Compiled Vue 2 assets that cannot be rebuilt on a supported Node version are an unpatched frontend bundle you now own.

Debugging order when the dashboard shows nothing: (1) config:show the published file to confirm env values are non-empty (config caching will mask a stale env — run php artisan config:clear); (2) run the ping command manually and read the exception verbatim; (3) check outbound egress and TLS to the base URL; (4) confirm the token is the one the dashboard issued for this environment. Most failures here are a stale config cache or a token/environment mismatch, not a code bug.

Do not let exceptions bubble. Wrap every call site. If a scheduled command throws on a failed HTTP call, Laravel's scheduler logs noise and can mask real failures in your own app. Fail silently, log to a dedicated channel, move on.

Schedule overlap protection is not optional. withoutOverlapping() plus a reasonable ->onOneServer() if you run multiple app instances. Without it, a slow or unreachable Mission Control endpoint produces a pileup of hung workers.

Extension point: your own wrapper command. The cleanest way to live with a low-maintenance package is to never call its artisan commands directly from your orchestration. Write one app/Console/Commands/ReportHealth.php that calls into the package, so you have a single file to change when the package is abandoned, replaced, or forked. That file is your exit strategy in concrete form.

Budget for owning the fork. Zero dependents means nobody else files the bugs you will hit, and no CVE feed watches this dependency. If it goes into any long-lived environment, assign a named internal owner and accept that "read the source" is your escalation path. If no one on the team wants that job, the ramp-up cost alone exceeds the value delivered — and that is a legitimate reason to reach for Telescope, Horizon, or a hosted equivalent instead.