When I started building Jottings, the biggest constraint wasn't compute power or databases—it was storage. Serverless functions are typically ephemeral by design. You spin up, do your work, and disappear. But when you're generating an entire static website from scratch, you need somewhere to work.

That's where Lambda's ephemeral storage comes in. And honestly, it's been a game-changer for how we build.

The Serverless Storage Problem

Traditional servers have persistent storage. You can write files to disk, accumulate assets, build complex artifacts, and everything just sits there. Lambda doesn't work that way. Each function invocation is a temporary sandbox. By default, you get 512MB of /tmp space—enough for small operations, but nowhere near enough for what we needed.

When you're generating a microblog as a static HTML site, you're not just creating a homepage. You're generating:

• Individual pages for every jot (post)
• Tag pages and tag clouds
• Archive pages organized by date
• JSON feeds and RSS feeds
• Search indexes for client-side search
• Sitemap files
• SEO metadata files
• Image assets with proper dimensions

For users with hundreds of jots, that adds up fast. A single user's site could generate 500+ HTML pages. With multiple images per jot, proper responsive variants, and all the supporting files, you're easily looking at several hundred megabytes of output.

512MB became a hard ceiling.

Then We Discovered We Could Ask For More

AWS Lambda offers a way to request more ephemeral storage—up to 10GB in /tmp. When I realized this was an option, I was genuinely surprised more people weren't using it.

Here's the thing: 10GB is massive for a ephemeral build operation. Suddenly, storage wasn't the constraint anymore. We could generate sites of any reasonable size, with plenty of breathing room.

Our build system requests the full 10GB. It costs us nothing extra. It's the same flat Lambda compute price, just with more scratch space.

How We Use It

The Jottings build system works like this:

1. A user publishes a jot or updates their site settings
2. We queue a build job via SQS
3. Lambda spins up and pulls the user's entire site data from DynamoDB
4. We use 10GB of /tmp as a working directory
5. We generate HTML for every page, build indexes, and write feeds
6. Once everything is built, we upload the entire site to Cloudflare R2
7. The /tmp directory is automatically cleaned up

The /tmp directory is our staging area. We write tens of thousands of files there, organize them in a proper directory structure, and validate everything before we push to production storage.

Having 10GB means we never have to worry about space constraints. We generate aggressively—multiple image variants, comprehensive indexes, detailed sitemaps. We don't optimize for size; we optimize for features. The build process is fast because it's not doing cleanup passes or trying to minimize disk usage.

The Build Pipeline In Action

Let me walk through an actual example. Say a user named Alex publishes 200 jots with an average of 2 images each. Our build system:

• Creates /tmp/build/{uuid} for this specific build
• Generates 200 individual jot pages (HTML + metadata)
• Creates 15 tag pages for Alex's categories
• Builds a 10-page archive with 20 jots per page
• Generates both RSS and JSON feeds
• Creates a full-text search index (JSON)
• Writes multiple sitemap variants
• Processes and stores responsive image variants
• Validates all internal links and consistency

All of this happens in /tmp. We're writing files in parallel, not worrying about disk space at all. Once the full site is built and validated, we do one massive upload to R2.

The upload itself is streamed—we don't load everything into memory. But having /tmp as a working directory means we can organize everything properly before we push.

Why This Matters For Static Sites

Static site generation is becoming popular again, but it has a dirty secret: you need somewhere to write all those files. Tools like Hugo or Jekyll are designed for your local machine where storage is infinite. Cloudflare Pages and Netlify handle this by running the build on their servers where disk space isn't metered.

On Lambda, you're working in a resource-constrained sandbox. Without adequate ephemeral storage, you'd be forced to:

• Generate fewer pages per user
• Store less redundant data (hurting performance)
• Use more memory (running out of RAM instead of disk)
• Split builds into smaller chunks (increasing latency)

10GB of /tmp lets us sidestep all of these tradeoffs. We can build comprehensive, feature-rich static sites without architectural compromises.

The Trade-offs

Of course, nothing is free. The constraints we work with:

Limited by build time: Lambda functions can run up to 15 minutes. For most sites, we finish builds in 30-60 seconds. But a very large site with thousands of jots could hit timeout limits. We haven't had to worry about this yet because the I/O of actually writing files is surprisingly fast.

No persistence: /tmp disappears when the function ends. This is fine for us—we're uploading everything to R2 anyway. But if you needed persistent working state between builds, you'd need something else.

Not suitable for databases: Ephemeral storage is temporary by design. If you need persistent data, DynamoDB or a proper database is the right call. We only use /tmp for generated output that gets uploaded elsewhere.

Regional limitations: If you want multi-region redundancy, you need to design for it. We deploy in one region and let Cloudflare handle global distribution.

Going Bigger Taught Me Something

Building Jottings with Lambda's ephemeral storage taught me that serverless isn't about choosing between convenience and capability. It's about choosing the right constraints for your problem.

We could have built Jottings with persistent servers, traditional databases, and complicated caching layers. Instead, we chose Lambda + DynamoDB + R2, and we let the constraints shape our architecture. The 10GB /tmp limit is so generous that it stopped being a limit and became an enabler.

If you're building a serverless application that needs to generate or process large amounts of temporary data—images, PDFs, static sites, reports—don't automatically assume you need external storage or instance storage. Check what ephemeral storage you have available. You might have more than enough already.

For us, 10GB in /tmp is doing heavy lifting. It's the reason our build system works the way it does, and it's one of those AWS features that doesn't get enough credit.

Jottings uses a fully serverless stack: Lambda for builds, DynamoDB for data, and R2 for storage. If you're curious about how we put it all together, you can explore the open source code or start your own microblog today.