Commercial email sandboxes are convenient: sign up, copy four values, done. But your test messages — with their headers, links and attachments — end up on someone else's servers, plans are metered per message, and indexing policies differ from vendor to vendor. This instance takes a different route: it runs on a single private host, for its own projects and people. Here is an honest breakdown so you can decide whether it fits you.
What this instance gives you
- One private host, no third-party copy. Messages and webhook payloads are stored in this instance's own database on its own server. No analytics service, no mail vendor and no external queue is in the loop.
- No metering. There are no per-message or per-user plans. The only limits are disk space and the retention window, which is a single setting.
- noindex everywhere. Share links, webhook captures and every application page answer
noindex, nofollow, noarchive, so a crawler cannot pick up a test email that happens to contain a real-looking address. - One address for SMTP and webhooks. Point your application and your providers at the same host; it works for local development and CI as well as for staging.
- Machine-readable output. A read-only share link also answers as JSON, so scripts and AI assistants can review captured mail without screenshots (see the AI guide).
What you trade
- It is one host. There is no vendor SLA, no multi-region failover and no support desk: if the host is down, the instance is down for everyone who uses it.
- The operator is your support. Updates, backups and certificates are handled by whoever runs the instance. That is usually an advantage (nothing to maintain on your side) and occasionally a limit (no 24/7 response, no audit log, no SSO).
- No self-hosting option. The code of this instance is not distributed, so you cannot run your own copy of it. If self-hosting is a hard requirement for your process, this is not the right tool — see the section below.
- Shared fate by design. Everyone who uses the instance shares its storage, its retention window and its uptime.
Side by side
| Commercial sandbox | This private instance | |
|---|---|---|
| Price | Free tier, then per message/user | Free, not metered |
| Where the data lives | Vendor servers | One private host |
| Third-party analytics | Usually yes | None |
| Retention | Vendor policy | A setting (DATA_RETENTION_DAYS) |
| Share links | Yes | Yes, with expiry and revoke |
| Indexing of test data | Varies | Explicit noindex everywhere |
| Machine-readable export | Usually an API key | Share token answers as JSON |
| Team features | SSO, roles, audit (paid) | Basic: accounts, admin role, share links |
| Self-hosting the code | No | No (not distributed) |
| Maintenance | Vendor | The operator |
If self-hosting is a hard requirement
Then this instance is not the answer, and it is better to know that before migrating. Look for a project that publishes a container image and a compose file, documents its upgrade path, and ships a licence you can live with. Budget the real cost too: updates, backups, certificate renewal and monitoring become yours, and so does the 2 a.m. page.
Switching from a commercial sandbox
Create an inbox, copy the host, port, username and password into your staging environment, send one message and confirm it appears in the dashboard. Keep the old configuration commented out for a day, then delete it. For webhooks: register the new URL with your provider and remove the old one after the first successful delivery. Nothing in your application code changes.