Wake

Wake is a self-hosted log sink for organisations running more than a couple of Laravel applications. Each application gets a wake log channel from a small client package; add it to the log stack and every line that application writes is shipped to one Wake deployment in your own Laravel Cloud account. Wake stores the lines as Parquet files on that deployment's bucket, keeps a catalog and a query plane in its PostgreSQL database, and serves the whole corpus to a coding agent over MCP.

Wake has no log viewer. That is a decision rather than a missing feature: the web pages are for adding an application and holding its credential, and reading the logs is something an agent does. With forty applications there is nobody who was going to read forty log streams anyway, and an agent can be asked "which apps are throwing this exception?" once.

Wake is open source under the MIT license. The server, the client (artisan-build/wake-client) and the shared wire contracts (artisan-build/wake-contracts) live in the artisan-build/wake repository.

Wake is Experimental in the Scalpels catalog, which here means the install path is complete and has not yet been run by anyone. Getting started says what the install does and what the one remaining manual step is.

What Wake does not do

There is no log search screen, no alerting, no anomaly detection and no dashboard. Wake takes no metrics and no traces, so it does not correlate logs against either. Nothing redacts your payloads on the way in: the client sends log lines exactly as your application wrote them, and filtering them is your code's job, covered in Connecting your apps.

The only thing that ships logs today is the Laravel client package. The HTTP ingest contract is published and another language could implement it, but nobody has, so in practice Wake collects from Laravel applications.

One Wake deployment serves one organisation. Anyone holding an MCP credential for it can read the logs of every application reporting to it, which is the point and also the thing to think about before you add an application whose logs you would not want a colleague to see.

How it fits with Scalpels

Scalpels forks Wake into your GitHub account, provisions its PostgreSQL database, managed queue, bucket and scheduler, installs the DuckDB binary during the build, runs its migrations and deploys it. It also connects the applications that report in: for each one it mints an ingest credential on your deployment, writes the two connection variables onto that application's environment, and opens a draft pull request adding the client package. Connecting your apps is the rest of the procedure, which is merging that pull request and adding wake to the application's log stack.

Give the deployment its own permanent domain before you point anything at it. The address you hand each application as WAKE_URL is the one it keeps, so moving it later means editing every reporting application.

In these docs

• Getting started: install through Scalpels, what the install provisions, and connecting your first application.
• Connecting your apps: the connect flow, the wake channel the log stack has to name, and redacting what should not leave the application.
• MCP tools: point an agent at Wake and what each of the ten tools answers.
• Retention and cost: how long lines are kept, what the storage costs, and which resource dominates the bill.
• Configuration: the per-application ingest caps, and the server settings that are compile-time rather than environment values.
• Troubleshooting: the failures we actually hit, and what each one looks like from the reporting application.