Automatic HTTPS and SSL on Voroa

Every Voroa service comes with free, automatic HTTPS. You don’t manage certificates, renewals, or configuration — it just works.

Your default domain

The moment you create a service, it’s reachable securely at:

https://your-app.onvoroa.com

The TLS certificate is provisioned automatically, so the connection is encrypted from the start.

Custom domains

When you add a custom domain like myapp.in, Voroa provisions an HTTPS certificate for it automatically once your DNS record is live. Nothing else to set up — the domain goes from Verifying DNS to secure and live on its own.

Certificates renew themselves

Certificates are issued by a trusted authority (Let’s Encrypt) and renew automatically before they expire. You never have to touch them.

Security headers Voroa adds for you

Voroa sets two response headers on every service, so you don’t have to:

• X-Content-Type-Options: nosniff — stops a browser from second-guessing your content types.
• Referrer-Policy: strict-origin-when-cross-origin — your URLs aren’t leaked in full to other sites.

On your Voroa address (.onvoroa.com, or .getvoroa.com for older services) we also send HSTS (Strict-Transport-Security), which tells browsers to only ever reach that address over HTTPS.

On your own custom domain, HSTS is off until you turn it on. Once a browser sees that header it will refuse plain HTTP for that hostname for up to a year, and nothing you or we send afterwards changes it during that time — so it is your decision to make about your domain, not ours.

To switch it on, open your service, go to Settings -> Custom domains, and tick Strict HTTPS (HSTS). It applies to every custom domain on that service, and takes effect on your next deploy.

Before you do, be sure every one of those domains serves correctly over HTTPS. Two things worth knowing:

• Turning it back off stops us sending the header, but browsers that already saw it stay on HTTPS-only for that domain until it expires. We cannot undo that for you.
• Keep it off if you still serve anything on plain HTTP for that hostname.

Headers your application sets — a Content Security Policy, X-Frame-Options, and anything else — are passed through untouched. Voroa never adds or overrides those: only your app knows whether it is meant to be framed or which sources it loads.

Protection against traffic floods

Voroa applies a per-visitor request limit at the edge of every service. A single address sending an unusual burst gets 429 Too Many Requests; normal traffic, including busy real-world usage, is well under the ceiling and is never affected.

This is a guard against single-source abuse — a runaway script, a scraper, repeated login attempts. It is not DDoS protection, and it is not a substitute for rate limiting inside your own application where your logic needs it.

Good to know

• Right after a new deploy, your service takes a short moment to build and start — during that window it may show a “deploying” state. Once it’s live, HTTPS is active.
• Always use https:// (and wss:// for WebSockets) — plain HTTP is upgraded to HTTPS for you.

Related

• How to add a custom domain on Voroa
• Does Voroa support WebSockets?