Self-hosted Laravel monitoring on a serverless $0 Postgres in about 15 minutes. Six steps, full screenshots, no credit card.
QUICK ANSWER
Can I run NightOwl on a free Neon Postgres database?
Yes — Neon's serverless Postgres is fully libpq-compatible, and the 0.5 GB free tier fits NightOwl telemetry comfortably for low-volume Laravel apps. Use the direct connection string (not the pooler), set retention to 2 days, and the database stays under the free-tier limit. Total setup time is about 15 minutes: create the Neon project, copy the direct connection string, paste it into NightOwl, install the agent, run it. Neon's autosuspend won't cause data loss — the agent buffers locally and retries on wake.
Updated · 2026-04-27
What you'll have at the end
A working NightOwl dashboard showing live telemetry from your Laravel app — requests, queries, jobs, exceptions, scheduled tasks — with all data stored in a free Neon serverless Postgres under your control. Total monthly cost: from $5 for NightOwl Hobby, $0 for the database.
END STATE
[ SCREENSHOT PENDING ]
NightOwl dashboard overview showing real Laravel telemetry — requests/min, p95 latency, recent exceptions, queue depth — sourced from the connected Neon Postgres.
What you're aiming for: live telemetry flowing from your Laravel app into Neon, surfaced on the NightOwl dashboard.
Why Neon free tier works for NightOwl
Three properties make Neon a clean fit for NightOwl's BYOD Postgres model:
Real Postgres 16, fully libpq-compatible — NightOwl uses native COPY, JSONB, and partial indexes; Neon supports all of it without a translation layer.
0.5 GB free storage — enough for 4-7 days of telemetry at small-app traffic with retention pruning.
Branching — useful when you want to test a NightOwl schema migration without touching production data.
Three catches worth knowing up front:
Cold starts on free-tier compute. Neon's free compute autosuspends after ~5 minutes of idle. The next query waits 500 ms to 2 s while compute wakes up. While your Laravel app is taking traffic, the agent's continuous drain keeps Neon warm — but the first dashboard load after an idle night can feel slow. This is Neon's free tier, not NightOwl.
Small free compute (0.25 vCPU autoscaling). Aggregation queries over multiple days of telemetry can take 1-3 seconds where a dedicated 2-core would take 100-200 ms. Same caveat — this is Neon, not NightOwl. Verify in Neon's own SQL editor; the same queries will be just as slow.
0.5 GB hard cap. Heavy traffic blows through this in days. Tune retention aggressively or upgrade to the Launch tier.
Step 1 — Create a free Neon project
Head to neon.tech, sign in, and click New project. Pick a region close to your Laravel app's server — same-region keeps the agent's drain latency under 10 ms.
Neon creates a default database called neondb with a randomly generated user and password. You can rename, but for NightOwl telemetry the defaults are fine.
STEP 01
[ SCREENSHOT PENDING ]
Neon 'New project' form with project name 'nightowl-telemetry', a region selector showing 'AWS us-east-1', and the default Postgres 16 version selected.
One project per Neon free account. Pick the region closest to your Laravel host.
Step 2 — Copy the direct connection string
On the project dashboard, find the Connection Details panel. Neon offers two connection types: Pooled (hostname has a -pooler suffix, transaction-mode pooled) and Direct (regular hostname, session-level).
Use the direct connection. NightOwl's drain uses Postgres COPY for batch ingestion — that doesn't work under transaction-mode pooling. The direct connection gives session-level semantics, which is what COPY needs.
STEP 02
[ SCREENSHOT PENDING ]
Neon project dashboard with the Connection Details panel open, the 'Pooled connection' toggle disabled, and the direct connection URI visible.
Direct connection URI looks like postgresql://[user]:[password]@ep-xxx-xxx.region.aws.neon.tech/neondb?sslmode=require. Copy it as-is — the password is embedded.
Note the sslmode=require at the end — Neon enforces TLS on every connection. Don't strip it.
Step 3 — Register the app in NightOwl
Sign in to the NightOwl dashboard (or start a free trial). Click New application and name it (e.g. "production-api"). The form has five separate database connection fields — parse the Neon direct URI by hand into them:
db_host — the hostname (e.g. ep-xxx-xxx.region.aws.neon.tech, no -pooler suffix)
db_port — 5432
db_database — neondb (Neon's default DB name)
db_username — the user from the URI (Neon generates a random one)
db_password — the password embedded in the URI
Click Test connection. NightOwl runs SELECT 1; on success the form unlocks. Save, and NightOwl issues an agent token. Copy it.
STEP 03
[ SCREENSHOT PENDING ]
NightOwl 'New application' dialog with five database fields filled in (db_host, db_port, db_database, db_username, db_password) and a 'Test connection' button below them.
If the test fails with a transaction-pooler error, the host you used has -pooler in it — re-copy the direct hostname from Step 2.
Step 4 — Install the NightOwl agent
In your Laravel project root:
bash
composer require nightowl/agent
Add the database connection details (same values you entered in Step 3) plus the agent token to your Laravel .env:
nightowl:install publishes config/nightowl.php and runs the schema migrations against the nightowl connection — creating all nightowl_* tables in your Neon database.
STEP 04
[ SCREENSHOT PENDING ]
Terminal output of 'php artisan nightowl:install' showing 'Published config/nightowl.php' and 'Ran migrations' against the nightowl connection.
If migrations error with a connection problem, double-check the NIGHTOWL_DB_* env vars match what you typed into the dashboard form in Step 3.
Step 5 — Start the agent and verify telemetry
Run the agent process. In dev:
bash
php artisan nightowl:agent
In production, supervise it the same way you supervise queue workers. docs.usenightowl.com has copy-paste Supervisor and systemd configs.
Now hit any route in your Laravel app. Within a few seconds, the request should appear in the Requests tab of the NightOwl dashboard. If Neon was suspended, the very first request will take a beat extra while compute wakes — that's the cold-start cost, not a NightOwl issue.
STEP 05
[ SCREENSHOT PENDING ]
NightOwl Requests tab showing the just-fired request with route, status code, p95 timing, and a 'received 3 seconds ago' badge.
If you don't see anything within ~10 seconds: check the agent's health endpoint at localhost:2409/health, then the connection string syntax.
Step 6 — Tune retention for the 0.5 GB free tier
Out of the box, NightOwl retains 14 days of telemetry. On a 0.5 GB Neon free tier, drop that to 2 days. Add this to your Laravel .env:
bash
NIGHTOWL_RETENTION_DAYS=2
Then schedule the prune command in routes/console.php:
php
use Illuminate\Support\Facades\Schedule;
Schedule::command('nightowl:prune')->daily();
Or run manually: php artisan nightowl:prune. This deletes rows older than NIGHTOWL_RETENTION_DAYS across all 11 telemetry tables. Single retention value — no per-table tuning at the moment.
STEP 06
[ SCREENSHOT PENDING ]
Terminal output of 'php artisan nightowl:prune' showing per-table delete counts after pruning, with the Laravel scheduler config visible alongside.
Schedule daily for steady-state cleanup. If your traffic is bursty enough that 24-hour growth alone could blow the 0.5 GB cap, run it hourly instead.
When to upgrade to Neon Launch
Four signals it's time to leave the free tier:
Cold starts on the dashboard frustrate you — Launch ($19/mo) gives you always-on compute. No autosuspend, no wake-up wait.
Dashboard pages take more than ~2 seconds to load even when warm — Launch unlocks bigger autoscaling, which usually drops query times by 5-10×.
Storage hits 80% of 0.5 GB even with 2-day retention — Launch gives you 10 GB and longer retention.
You need 30+ day retention for incident post-mortems — at typical SaaS traffic, that's well past 0.5 GB.
Total stack at that point: $15 NightOwl Team + $19 Neon Launch = $34/month, all-in. Compare that to Sentry or Datadog at equivalent volume.
Neon vs Supabase for NightOwl
Both work. Pick based on your usage shape:
Neon if you want serverless billing, branching, and don't mind cold starts on idle. Better for lower-traffic apps where the database stays warm only during active hours.
Supabase if you want always-on compute on free tier (no cold starts), broader ecosystem, and don't need branching. Slightly more storage on free (500 MB ≈ 0.5 GB, comparable).
THE QUICK PATH
Already have a Neon URI? Skip to install.
Two commands plus the agent token. No Docker, no Postgres ops, no infrastructure to maintain.
From $5/month flat for NightOwl. 14-day free trial. Database stays $0 on Neon free tier.
Frequently asked questions
Does NightOwl run on a free Neon Postgres?
Yes. Neon is a serverless Postgres — fully Postgres-compatible from NightOwl's perspective. The free tier gives you 0.5 GB of storage, one project, branching, and autoscaling compute. NightOwl writes telemetry over a standard libpq connection just like any other Postgres host. Setup takes about 15 minutes.
Why does the NightOwl dashboard feel slow on Neon free?
Two reasons, both Neon's free tier — neither is NightOwl. (1) Cold starts: free-tier compute scales to zero after 5 minutes of idle. The next query waits 500 ms to 2 s while compute wakes up. NightOwl's continuous drain keeps it warm during traffic, but the morning's first dashboard load after an idle night can feel slow. (2) Free compute is small (0.25 vCPU autoscaling) — aggregations over a few days of telemetry can take 1-3 seconds where dedicated compute would take 100-200 ms. Both go away on the Neon Launch tier ($19/mo) which gives you always-on compute and bigger autoscaling. *This is the database, not NightOwl* — you can verify in Neon's SQL editor where the same queries are just as slow.
Should I use the pooled or direct connection string?
Use the direct connection (the hostname without the `-pooler` suffix). NightOwl's drain uses Postgres COPY which doesn't work cleanly under transaction-mode pooling. Direct connections give session-level semantics — exactly what COPY needs. Neon handles connection scaling on the compute side, so you don't lose much by skipping the pooler for NightOwl traffic.
Will autosuspend break my monitoring?
Not for the writes themselves. The agent buffers telemetry locally in SQLite WAL and retries the drain every few seconds. When Neon wakes up (usually under a second), the buffered batch is sent. The user-visible effect is only on dashboard loads after a long idle gap — see the slow-dashboard FAQ above.
How much telemetry fits in 0.5 GB?
About 4-7 days for a low-volume Laravel app at 50-200 requests/min. Heavy traffic shortens that. NightOwl prunes by retention setting — drop request/query/job retention to 2 days on the free tier and you'll comfortably stay under the limit. If you need 30+ day retention, the Neon Launch tier ($19/mo) gives you 10 GB.
Does Neon's branching feature work with NightOwl?
Yes, but it's not part of normal monitoring flow. Branching is useful for testing schema changes — you could branch your NightOwl telemetry database, run a migration test, then drop the branch. For day-to-day ops it's irrelevant. Branches share storage allocation, so don't leave dozens lying around on the free tier.
Is my data exposed to NightOwl?
No. NightOwl is BYOD — telemetry never leaves your infrastructure. The agent installed in your Laravel app writes directly to your Neon project. The hosted dashboard reads on demand using credentials you provide; they're encrypted at rest and only decrypted per request. No telemetry is mirrored to NightOwl servers.
PRICING
Flat pricing. No event caps. No per-seat fees.
14-day free trial, no credit card. Your PostgreSQL, your data.
HOBBY
$5/month
1 app · 14 days lookback · all Laravel events
TEAM
$15/month
Up to 3 connected apps · unlimited environments · all Laravel events
AGENCY
$69/month
Unlimited apps · unlimited agent instances · same flat rate at any traffic