Skip to content
Scalpels home

Scalpels is officially launching on October 31, 2026. Special early adopter pricing is available now.

← All documentation

Documentation

Muster

Getting started

Updated

You install Muster the same way as any other app in the Scalpels catalog. Connect GitHub and Laravel Cloud, open Catalog, select View requirements on Muster, choose a region and deploy. Install a product describes each step and how to resume an install that fails partway. Muster is Experimental, so starting a new install needs the Supporter tier or a partner team.

What the install provisions

Muster's manifest asks for exactly these on your Laravel Cloud account:

Resource What Muster uses it for
Compute, on PHP 8.5 The web UI, the check-in API and the MCP endpoint.
A Postgres 18 database (Neon serverless) Monitors, check-in history, run records, alert deliveries and the weekly digest ledger.
A managed queue Every alert email, webhook call and digest email is sent from the queue.
The scheduler Runs monitors:evaluate every minute, which is what notices a missing check-in.

There is no object storage and no cache. Muster stores no task output, so it has nothing to put in a bucket. Laravel Cloud injects the connection settings for the database and queue itself.

The scheduler and the queue are not optional extras. Without the scheduler, nothing ever goes late or missed, and every screen still looks healthy. Without a queue worker, alerts are recorded but never delivered.

After the deploy, the install runs php artisan migrate --force, which creates Muster's tables. There is no build step.

Environment values

Muster adds no environment variables of its own, and none are required. On a Scalpels-managed installation, the default Scalpels mailer delivers transition alert emails and weekly failure digests without additional configuration. See Configuration.

Sign in

Muster has no public sign-up. Every Built for Cloud app has the same sign-in page at /bfc/login and account screen at /bfc/ui; in Muster the account screen is where you manage members, sessions and access tokens. The first account on an instance is its Owner.

On a deployed instance, the first account is created from the command line in a checkout of your fork, using the Laravel Cloud CLI:

php artisan create-admin --environment=<env> [email protected] --name="Your Name"

It prompts for the password on your machine, hashes it there, and sends only the hash to the environment. The plaintext password never travels and never appears in a command line. Run it a second time and it refuses, unless you pass --force, which creates an Admin instead of another Owner.

Whether an installation uses Scalpels for sign-in instead is chosen per installation by its Owner, inside the app. See Use Scalpels from your agent.

After signing in you land on /bfc/ui. Your monitors are at /monitors, which says No monitors have been created yet. on a new instance. The Monitors and Account links in the header move between the two.

Check that it is watching

Four things have to be true. The first two being true tells you nothing about the last two.

  1. It serves. The environment URL answers and /monitors loads after you sign in.
  2. It has something to watch. Connect an application or create a monitor by hand and send it one heartbeat. A monitor created by hand stays pending until its first check-in.
  3. The scheduler runs. Let a monitor go overdue on purpose. Without you doing anything, it should reach late and then missed. If it stays healthy past its due time, the scheduler is not running for the environment.
  4. The queue drains. Create a throwaway monitor with a short cadence, point its webhook alert at a URL you control that returns 200, let it go missed and confirm the request arrives. Disable the throwaway monitor afterwards.

Next steps