Is Render Safe? Env Vars, Public Services & Missing HSTS

Managed Security

Render handles much of the operational security work: automatic OS patching on managed services, managed TLS certificates, DDoS absorption, and private services that aren’t reachable from the public internet. Defaults are safe: private services are private, HTTPS is on, managed Postgres is encrypted at rest, and free-tier services spin down when idle.

Because the platform defaults are safe, the findings on Render projects sit at the application layer: API endpoints without rate limits, env vars copied across environments, custom domains without HSTS, and database access lists left wide open after the migration finished.

Security Considerations

Private Services

Use Private Services for anything that doesn’t need public traffic - workers, internal APIs, queue consumers, scheduled jobs. They’re reachable only from other services in the same Render workspace, on the internal <service>.onrender.com hostname. They have no public URL at all, which removes them from drive-by scanners.

# render.yaml
services:
  - type: web
    name: api
    env: node
    plan: starter
    buildCommand: npm install && npm run build
    startCommand: npm start
  - type: pserv     # private service, no public URL
    name: worker
    env: node
    plan: starter
    buildCommand: npm install
    startCommand: npm run worker

If you started with a Web Service and later realized it should be private, you have to re-create it as a pserv - there’s no in-place flip.

Database Security

Render’s managed Postgres is encrypted at rest, supports SSL connections, and gives you both an internal hostname and an external one. The external hostname is gated by an Access Control allowlist that defaults to wide-open (0.0.0.0/0) on the free and starter tiers in some legacy projects. Audit it.

# Verify your DB is reachable only from your services and your office IP
# Render Dashboard → Database → Access Control → trim to:
# - Render-internal traffic (always allowed)
# - Office egress IPs only

Use the internal connection string (postgresql://user:pass@dpg-xxx-a/db) from inside your services. Use the external one only for migrations from CI or local debugging - and remove the IP from the allowlist when you’re done.

Environment Variables

Render groups env vars into Environment Groups that can be shared across services. The pattern that bites: a single production env group shared with a staging service, exposing prod secrets to a less-protected environment.

# render.yaml - separate envGroups per environment
envVarGroups:
  - name: prod-secrets
    envVars:
      - key: STRIPE_SECRET_KEY
        sync: false        # do not sync to staging
  - name: staging-secrets
    envVars:
      - key: STRIPE_SECRET_KEY
        sync: false

Build logs are visible to all team members. Audit your build scripts for printenv, env, or framework debug output that prints process.env.

Application Security

Render manages the platform; authentication, authorization, input validation, rate limiting, and HTTPS-only cookies are yours. Render does not provide a built-in WAF, rate limiter, or auth shim - these belong in your application or behind a Cloudflare in front.

Specifically: HSTS is not set automatically. Add it from your application:

// Express
app.use((req, res, next) => {
  res.setHeader('Strict-Transport-Security', 'max-age=63072000; includeSubDomains; preload');
  next();
});

Background Workers and Cron

Background workers and cron services often inherit the API service’s env vars, including secrets they don’t need. Scope them down. A worker that only needs read access to one queue should not have your Stripe secret key in scope.

Common Render Security Mistakes

Database access control left at 0.0.0.0/0 after the initial migration.
Web Services that should have been Private Services, exposing internal APIs to the public internet.
A single prod-secrets env group shared with staging or PR preview environments.
HSTS not set, so a downgrade attack via a stale HTTP link still works.
Build logs containing npm postinstall output that printed env vars.
Cron services running with full-API env scope, which widens the blast radius if compromised.
Custom domains added without setting up the HTTPS redirect (Render handles cert; you handle the 301).

Comparison vs Railway and Fly.io

Render: safe defaults and a simple UI, hard to misconfigure. Less flexible. Fits teams that want minimal config.
Railway: similar tier, more templates, and more room to misconfigure via one-click deploys. Fits teams that iterate fast and audit their own config.
Fly.io: Firecracker VM isolation, raw networking primitives, better for multi-tenant or regulated workloads. Steeper learning curve.

For a typical SaaS, Render is a low-risk default. Move to Fly.io when you need stronger isolation or finer control over networking.

Enterprise Considerations

SSO: SAML SSO on Team plan and above. Below that, accounts are GitHub/Google identities.
Audit Logs: Workspace audit log; export via API to your SIEM.
Compliance: SOC 2 Type II; HIPAA available with a BAA on Enterprise. Confirm scope with their team if regulated.
DDoS: Built-in protection on all plans. For sustained attacks, Render does not yet offer the Cloudflare-tier knobs; put Cloudflare in front for high-risk projects.
Secret rotation: No built-in rotation. Use Doppler/Infisical, or rotate via the Render API on a schedule.

Security Assessment

Strengths

- SOC 2 Type II compliance
- Automatic HTTPS with managed certificates
- Private services for internal communication
- Encrypted environment variables and shared Environment Groups
- DDoS protection on all plans
- Automatic security updates for managed services
- Managed Postgres encrypted at rest
- Safe defaults across most settings

Concerns

- Application security is developer responsibility
- Database access control sometimes defaults to wide-open on legacy projects
- HSTS is not set automatically
- Free tier services have spin-down behavior that can mask issues
- Background workers often run with broader scope than they need
- Environment Groups can leak prod secrets to staging if shared
- No built-in WAF or rate limiter

The Verdict

Render is a safe deployment platform with strong managed security and SOC 2 compliance. The findings live at the application layer and in three platform-specific gotchas: tight database allowlists, separate Environment Groups per environment, and explicit HSTS in your app code.

How to Secure Render

Step-by-step guide covering Private Services, database access control, Environment Group scoping, and the application-side hardening Render expects you to do.

Render Security Checklist

Interactive checklist for launch-blockers and the quarterly review.

Is Railway Safe?

Side-by-side analysis of the two most popular DX-first platforms.

Scan Your Render App

Let VibeEval scan your Render deployment for security vulnerabilities, including the open-database-allowlist, missing-HSTS, and over-scoped-worker patterns above.