Static is underrated (and why we only do static)

Every hosting platform eventually adds serverless functions. It's the obvious next feature, the thing the roadmap wants, the box the RFP asks for. We looked at that road for a long time and decided not to walk down it. Triangle deploys static sites — HTML, CSS, JavaScript, assets — and nothing else. That's not a phase. It's the point.

"Static only" reads like a limitation. We think it's the single most valuable decision in the product, and the rest of this post is why.

A stop-line is a design

When you refuse to run arbitrary code at request time, an enormous class of problems simply stops existing. There is no cold start, because there is no start — the file is already sitting on the edge. There is no runtime to exploit, because there is no runtime. There is no per-request compute bill that spikes when you get popular, because serving a cached file costs effectively nothing. Every one of those is a property you get by subtraction, and subtraction is the most durable kind of engineering.

Contrast that with the alternative. The moment you can run functions, you inherit their entire surface area: version pinning, dependency drift, execution timeouts, memory limits, regional cold starts, a new security boundary at every endpoint, and a bill that's now coupled to traffic in ways that are hard to predict. None of that is wrong to take on — plenty of products need it — but you don't get to opt out of the cost just because you opted into the capability.

What static buys you, concretely

• Speed with no asterisk. A static asset is cacheable end to end. The fastest response is one that never touches an origin, and static is the only model where that's the default rather than an optimization.
• A smaller attack surface. No server-side execution means no injection into a runtime, no leaked environment at request time, no dependency with a CVE running in production. The threat model shrinks to "who can change the files."
• Predictable cost. Serving bytes is cheap and scales linearly. That's why Hobby can be free forever and degrade gracefully instead of surprising you with a bill — there's no compute meter running underneath.
• Instant everything. Because deployments are just immutable sets of files, rollback is a pointer move, previews are free, and there's no warm-up before a deploy is "ready."

The fastest, safest, cheapest request is the one your server never has to think about. Static hosting makes that request the default, not the exception.

The honest part: what we can't do

We won't pretend static is universal. If your app needs to run code on the server for every request, Triangle is the wrong tool and we'd rather tell you now than after you've wired half of it up. Specifically, there are no serverless functions, no server-rendered pages computed at request time, and no backend you can write against on our platform. If you need those, you need a different host, and that's fine.

Here's the thing, though: "static" today is far larger than "static" a decade ago. You can build genuinely dynamic experiences on top of static delivery by moving the dynamic parts to the client and to services you call from the browser:

// shipped as static files, dynamic at runtime
const data = await fetch("https://api.your-backend.com/v1/items")
  .then(r => r.json());
render(data); // auth, payments, DB — all called from the client
                // or an external API you own. Triangle just serves the shell.

Fetch data from your own API. Handle auth with a hosted provider. Take payments through a client SDK. The static shell loads instantly from the edge, and the dynamic behavior lives where it can scale on its own terms. For a huge fraction of sites — marketing, docs, portfolios, dashboards, landing pages, tools — that's not a compromise. It's the better architecture.

Who should look elsewhere

If your product is fundamentally a server — a monolith that renders per request, a service that can't push its logic to the client, an app where "the backend" is the thing you're deploying — we are not your host, and no amount of us wishing otherwise changes that. Use a platform built for functions.

But if what you're shipping is a fast site that talks to services, static isn't the ceiling you're settling under. It's the floor you get to build on — solid, quiet, and already at the edge. We only do static because static, done seriously, is enough for most of what the web actually is.

Sofia Reyes works on the Platform team at Triangle, where "static only" is the feature, not the caveat.