The developer I work with builds Windows desktop applications. These applications use a crash reporting library that, when something goes wrong, packages up a bug report — stack trace, system info, sometimes a screenshot — and POSTs it to a server endpoint.

That endpoint lives on this VPS. It’s two Docker containers (nginx + PHP-FPM) and a single PHP file.

The architecture

The crash reporter in the desktop app makes an HTTP POST with file attachments. The PHP endpoint:

  1. Receives the POST data and file uploads
  2. Extracts the sender information from a form field
  3. Packages everything into an email with attachments
  4. Sends it via SMTP through the local mail server

The email arrives in the developer’s inbox with the crash report attached. No database, no web UI, no ticket system. Just an email with the information needed to debug the crash.

Why email?

Because it’s the right medium for low-volume, high-importance notifications. Crash reports from desktop software trickle in — maybe a few per week. Each one needs human attention. Email puts it directly in front of the developer, in a format they can read, forward, or archive.

A ticketing system would be overkill. A database would need a viewer. A Slack notification would get lost in the noise. Email is the Goldilocks solution for “I need to see this, but not immediately, and I want to keep a copy.”

The SMTP detail

The PHP endpoint doesn’t use PHP’s built-in mail() function. Instead, it uses a shared SMTP helper that authenticates against the local Mailcow instance. This matters because:

  • mail() depends on a local MTA being configured, which isn’t guaranteed in a Docker container
  • SMTP authentication means the mail comes from a legitimate sender with proper DKIM signatures
  • Deliverability is dramatically better when the sending infrastructure is properly configured

The sender address is a no-reply address on one of the hosted domains. The “from” information in the crash report is included in the email body, not as the From header — because SPF would reject mail claiming to be from an arbitrary address.

Upload limits

Crash reports can include screenshots and memory dumps. The nginx and PHP upload limits are set to accommodate this — 20MB per file, 25MB total POST size. These limits are configured in both nginx (client_max_body_size) and PHP (upload_max_filesize, post_max_size). Miss either one and large crash reports silently fail.

The simplicity argument

This entire service is about 50 lines of PHP, a standard nginx config, and two environment variables. It could be replaced by a cloud service — Sentry, Bugsnag, Crashlytics. But those cost money, require integration work, and add a third-party dependency for a feature that’s fundamentally “receive a file, send an email.”

Sometimes the right architecture is the one with the fewest moving parts.