MailHulk: real inboxes for automated tests
Signup, password reset, magic link, one-time code: the flows that matter most are the ones a test suite handles worst, because an email has to arrive. MailHulk gives each test its own inbox, captures the message, and hands back the code and links already parsed — so the test asserts on a real email instead of a mock, and never calls sleep().
The problem
Teams running Playwright, Cypress or API tests in CI all hit the same wall. The email either goes to a shared inbox that parallel runs fight over, or it is mocked away and the flow is never really tested. When a run fails, the evidence is a bare “no message” and someone re-runs it by hand. The workaround is usually a polling loop with a sleep in it, which is slow when it works and silent when it does not.
What it does
A test creates an inbox, triggers the app under test, then waits on one call that returns as soon as the message lands or the deadline passes. The response carries codes[] and links[] already extracted, so the next line of the test is the assertion. Ephemeral inboxes expire on their own; persistent mailboxes on a custom domain serve nightly regression runs. The same message is available by signed webhook, and over POP3 and IMAP for tools that only speak mail.
Around that core sit the pieces a QA team ends up building anyway: a scenario engine that runs deterministic email journeys and keeps the evidence, an authenticator vault so a TOTP code lands next to the email instead of on someone’s phone, an Android companion that puts the code into the form on the device being tested, and an MCP server so an AI agent can drive the same API.
Built with restraint
Mail ingestion is a separate Go service that knows nothing about tenants; it writes to object storage and a queue, and the Laravel side does the rest. That boundary is what keeps the receiving path simple enough to trust. MailHulk does no AI inference of its own, and the roadmap deliberately avoids “unlimited” as a headline: quotas are the product being honest about cost.
Where it is today
The application and the real mail plane are built and running on our own infrastructure. Outbound sending is switched off on purpose while the product is receive-only. Payments through a merchant of record are in progress; private beta and public launch are planned and not yet dated. There are no customers to quote, so this page quotes none.
Screens on this page are MailHulk running on a seeded demonstration database: every team, inbox, sender and message is fictional. No usage figures or customer names are shown because the product has not launched.
Four screens, one loop
Create an inbox, trigger the app, wait for the message, assert on what was parsed. Everything else on the dashboard exists to make that loop observable when it breaks.