Static Sites on Render

Some products do not need a server at all. A landing page, a portfolio, a brochure site for a local business — these are just pages, styles, and scripts that can be built once and served as files. When your blueprint fits this shape, Idea to Life deploys it as a Render static site instead of a web service, and that is good news for you.

How static sites work

At deploy time, Render runs the build command and takes the resulting folder of HTML, CSS, JavaScript, and images, then serves those files from a global CDN (a network of servers near your users). There is no Node process running for your site, which means:

• Speed: files served from a CDN edge are consistently fast worldwide.
• Robustness: there is no server to crash, no cold starts, no memory limits at runtime. The failure modes of web services largely do not exist.
• Cost: Render hosts static sites free within generous bandwidth limits, with paid tiers only at scale. Of all deployment types, this is the one where "free" is usually the honest answer.

Static sites still get HTTPS automatically, custom domain support, and deploy previews. Cold starts do not apply — free static sites do not spin down, because there is nothing to spin down.

What static sites can and cannot do

Can:

• Any number of pages, responsive design, animations, images, downloadable files.
• Client-side interactivity: image galleries, tabs, calculators, anything that runs in the visitor's browser.
• Contact forms and similar, via third-party form endpoints or a lightweight external API.
• Calling external APIs directly from the browser — but only with keys that are safe to expose. A static site has no server, so it has nowhere to hide a secret.

Cannot:

• Store data itself, run scheduled jobs, send email directly, or hold API keys like OPENAI_API_KEY or SUPABASE_SERVICE_ROLE_KEY. Anything embedded in a static site's files is public.

When your product outgrows static

If you start with a landing page and later want bookings, logins, or AI features, the product needs server-side capability. That is a normal evolution: request the feature and the platform migrates the project to a web service (see the Web Services guide), typically alongside adding Supabase for data. Migrating this way is routine, though be aware the web service tier has different cost characteristics than free static hosting — the change request estimate will say so.

Environment variables

Static sites can use environment variables at build time only — values are baked into the files during the build. This is fine for public configuration (a public analytics ID, a Supabase anon key) and unsafe for secrets, which is exactly the NEXT_PUBLIC_ rule described in the Environment Variables guide.