How we render fully custom emails for roughly 30× less

A custom snapshot built from Freestyle's 128 MiB BusyBox base, an 18-second average runtime, and per-second billing let us keep every email flexible without paying for a general-purpose sandbox.

At a glance

• Custom snapshot derived from Freestyle's 128 MiB BusyBox base
• Tens of thousands of VMs launched, one per email
• About 65 ms from API request to a ready Freestyle VM
• 18-second average render runtime
• About 30× lower cost than the equivalent workload on our previous sandbox provider

Email is part of the product

At Hexclave, email is not an add-on. It is part of the product experience we help our customers create. From transactional messages to marketing campaigns, teams can use one API, shape templates around their brand, and generate content from application data.

That flexibility turns each send into a small compute job. We need to produce the subject, HTML, plain-text body, and delivery metadata, then hand the result to an email provider. The work needs to be isolated and repeatable, but it usually lasts only a few seconds.

The challenge

A general-purpose sandbox is a poor economic fit for a short email render. Our previous sandbox provider defaulted to 2 vCPU and 4 GB of memory, and its provisioned memory carried a one-minute billing minimum. Our renderer does not need that footprint or billing window.

Keeping a renderer warm would avoid startup work, but it would also mean paying for idle capacity. Packing more jobs into a long-lived process would reduce isolation and make failures harder to contain. We wanted each render to have a clean environment without turning every email into a minute of general-purpose compute.

The solution: a snapshot shaped around one email

We built a custom render snapshot from Freestyle's 128 MiB BusyBox base. The image contains only the runtime and dependencies needed to turn an email job into its final artifacts. There is no package manager or general-purpose operating-system layer in the hot path.

When an email worker claims a job, it starts one VM from the snapshot for that email, passes in the template and application data, and receives the rendered subject, HTML, plain-text body, and metadata. Hexclave runs tens of thousands of these short-lived VMs. Each one handles a single email, averages 18 seconds, and is deleted as soon as the rendered result returns.

This keeps the rendering boundary simple. Hexclave launches every VM from the same snapshot, failures stay within one disposable environment, and we do not maintain a pool of idle render workers.

How it works

The renderer sits inside Hexclave's durable email pipeline. An API request creates an outbox record for each recipient. A worker starts one VM for that email, renders the message, checks the latest delivery preferences, sends it through the configured provider, and records the outcome.

1. A Hexclave app requests an email.
2. Hexclave creates an outbox job per recipient.
3. A worker claims an unrendered job.
4. The worker starts one tiny Freestyle VM for this email from our custom BusyBox-based snapshot, ready in about 65 ms.
5. The VM renders the subject, HTML, plain-text body, and metadata and returns them to Hexclave. If rendering fails, the error is recorded for a safe retry.
6. Hexclave applies the recipient's current delivery preferences and sends the message through the configured email provider.
7. Hexclave stores the delivery status and provider response.
8. The VM is deleted. Average lifetime: 18 seconds.

Why the economics work

Three choices account for most of the difference.

Right-sized memory. Our custom snapshot starts from Freestyle's 128 MiB BusyBox base instead of a multi-gigabyte default sandbox. Each VM matches the renderer rather than a broad development environment.

Billing that matches the job. Freestyle meters compute per second. Our previous provider billed provisioned memory with a one-minute minimum. When the average run lasts 18 seconds, the billing shape matters as much as the headline unit price.

A disposable lifecycle. Freestyle provisions VMs in about 65 ms from API request to ready machine. That startup time lets us launch one VM per email on demand and delete it when the artifacts return, without paying to keep a warm pool idle between sends.

Across our workload, these choices make the Freestyle path roughly 30× lower cost than the equivalent setup on our previous sandbox provider. That figure is specific to our runtime profile and configuration, not a universal ratio for every sandbox workload.

The result: custom email without the sandbox tax

The biggest result is not the VM itself. It is that infrastructure cost no longer pushes us toward less customizable email.

Customers keep the product experience they care about: branded templates, dynamic content, and one API for transactional and marketing messages. We keep a small, repeatable render environment whose cost follows actual work. Because rendering is part of a durable outbox flow, errors can be recorded and retried without losing the surrounding delivery state.

The system is easier to reason about, too. A render starts, produces a known set of artifacts, and disappears. The email pipeline owns scheduling, preferences, delivery, and status; the VM owns only rendering.

Infrastructure should match the work

Email rendering is short-lived by nature. Our infrastructure now is, too.

By designing the runtime around one email instead of starting from a general-purpose sandbox, we kept customization on the product path and made its economics sustainable. Freestyle is the disposable render layer underneath that experience: start small, render the message, return the result, and shut down.