Platform target

Render

Render static sites use a build command and publish directory. Nift keeps its normal public/ output and creates equivalent Blueprint configuration.

Create and build

nift init --target=render
nift build --all
nift status

What Nift creates

services:
  - type: web
    name: nift-site
    runtime: static
    buildCommand: nift build
    staticPublishPath: ./public

Change name before creating the service. render.yaml is user-owned after initialization and should remain the source of truth if the service is managed as a Blueprint.

Make the build reproducible

The generated command assumes nift is on Render's build PATH. Add an explicit, pinned installation step appropriate to the repository, then print the selected version before building:

services:
  - type: web
    name: nift-site
    runtime: static
    buildCommand: ./scripts/install-nift 4.0.7 && nift version && nift build --all
    staticPublishPath: ./public

A project-owned script may install a checksum-verified release archive, use an approved package channel or build reviewed source. Avoid an unrecorded “latest” dependency in production deploys.

First deployment

1. Push the repository with render.yaml and the installation script.
2. Create a Blueprint from the repository and review the proposed static service.
3. Confirm the build log reports the expected Nift version and a successful full build.
4. Inspect the generated onrender.com URL before attaching a custom domain.
5. Verify nested pages, a deliberate 404, response headers and browser assets.

Render can automatically deploy repository changes or accept manually triggered deploys. Decide which branch is production and protect that branch according to the repository's release process.

Redirects, rewrites and headers

Render static sites support redirects/rewrites and custom response headers through the service configuration and dashboard. Use redirects for moved public URLs, rewrites only when another resource genuinely owns the request, and response headers for security or cache policy.

Keep one source of truth. If rules live in the Blueprint, avoid maintaining conflicting dashboard-only copies. If the team intentionally manages them in the dashboard, document that operational state because it is not visible in the repository.

Cache policy

HTML with stable URLs should normally revalidate so a deployment becomes visible promptly. Content-hashed assets can use a long immutable lifetime; stable names such as dashboard.js should not. Inspect actual response headers after deployment rather than assuming the configured rule matched.

Custom domains and TLS

Add the domain to the static service, configure the DNS records Render requests, then verify the domain in the dashboard. Render manages certificate creation/renewal and redirects HTTP to HTTPS for verified custom domains. DNS propagation can delay verification; avoid repeatedly changing valid records while caches expire.

When the site needs a backend

Render web services, private services, workers and databases are separate resources rather than code executed inside a static site. A common architecture is:

Render static site
  └─ Nift-generated public/
          │
          └─ HTTPS /api
                  ▼
             Render web service
                  │
                  └─ database / background workers

The static frontend and backend can share a Blueprint while retaining separate build/runtime ownership. Configure CORS, cookies and authentication for the actual domains involved.

Troubleshooting

Official references: Blueprint specification, static sites, static-site headers, custom domains, and deployment troubleshooting.