Security
How Runex keeps your apps secure.
Runex secures apps with layered controls: an isolated container per app, HTTPS on every URL, a private network per project, verified GitHub webhooks, and role-based access. This page explains each control and what it protects against.
- Container per app
- HTTPS everywhere
- Private network per project
- isolation
- container per app · cpu + memory limits
- transport
- HTTPS / TLS on every URL
- network
- private per project
- webhooks
- verified
- access
- roles + audit log
- compliance
- no certifications claimed
Controls
What security controls does Runex use?
Six controls, each with a clear job. Together they limit what a bug, a leaked key, or a bad deploy can reach.
Container isolation
Each app runs in its own container, not on the host.
HTTPS on every URL
TLS for *.runex.cloud and custom domains.
Private networking
Services talk inside the project's own network.
Verified webhooks
Deploys trigger only from authenticated GitHub events.
Resource limits
CPU and memory caps stop one app starving others.
Roles and audit log
Per-project permissions; every change is recorded.
Isolation
How does container isolation protect my app?
Each app runs in its own container with its own filesystem, processes, and resource limits. A problem in one app stays in that app.
A container is an isolated process environment: it has its own filesystem and process list, and it can only use the CPU and memory it's given.
Runex runs every deployed app in a separate container instead of directly on the host operating system. That shrinks the blast radius: the set of things an attacker could reach if one app were compromised.
Example: if a vulnerable package in one app lets an attacker run code, they land inside that app's container, not on the host, and not inside your other apps.
Network
How is traffic between services protected?
Public traffic uses HTTPS; internal traffic stays on the project's private network. Only the services you expose get a public address.
Every public URL on Runex, the *.runex.cloud address and any custom domain, is served over HTTPS, so traffic between users and your app is encrypted.
Services in the same project, such as an API and its database, reach each other by internal hostname on a private network. Services in other projects can't reach them.
Databases have no public address by default. If you must reach a non-HTTP service from outside, you opt in with a TCP proxy.
Secrets
How should I handle secrets on Runex?
Store them as environment variables, never in your repository. Runex injects them into the container at runtime.
-
You
Add a variable
Set API keys and DATABASE_URL in the dashboard.
-
Runex
Inject at runtime
Values reach the process, not the Git history.
-
You
Separate previews
Give preview deployments their own values.
-
You
Rotate when needed
Update the value and redeploy.
Shared responsibility
What does Runex secure, and what do you secure?
Runex secures the platform; you secure your code and its secrets. This split is called the shared responsibility model.
| PlatformRunex | Your appYou | |
|---|---|---|
| Host OS and container runtime | Patched and operated | Nothing to do |
| TLS certificates | Issued and renewed | Nothing to do |
| Isolation and network boundaries | Enforced per app and project | Nothing to do |
| App code and dependencies | Not managed | Keep packages updated |
| Secret values | Injected at runtime | Create, scope, and rotate |
| Who has access | Enforces roles | Assigns roles, removes leavers |
Compliance
Is Runex SOC 2 or ISO 27001 certified?
No. Runex does not currently hold SOC 2, ISO 27001, PCI DSS, or HIPAA certification. If that changes, this page will list the certification and its scope.
Compliance certifications are independent audits of a company's security controls. Some industries require vendors to have them.
If your contract or regulator requires a certified hosting provider today, choose a provider that holds that certification.
To report a vulnerability, contact the Runex team through the channels on runex.cloud and avoid posting exploit details publicly before a fix ships.
FAQ
Security questions
What teams ask before they deploy.
Is my app isolated from other customers' apps?
Yes. Each app runs in its own container with its own filesystem, processes, and CPU and memory limits, and each project has its own private network.
Can other projects reach my database?
No. Databases join your project's private network and have no public address unless you expose one through the TCP proxy.
What is the shared responsibility model?
It's the split of security duties between a platform and its users. Runex secures the host, runtime, TLS, and isolation; you secure your code, dependencies, and secret values.
How are GitHub webhooks verified?
Runex checks each webhook's signature against the GitHub App's secret, so a deploy only starts from an authenticated GitHub event, not an arbitrary request.
Next step
Deploy with safe defaults.
HTTPS, isolation, and a private network are on from your first deploy.