Security at Runex

Each deployed application runs inside its own container/environment rather than directly inside the host operating system. The goal is to reduce the blast radius if a single workload is compromised.

Containers are the primary isolation boundary for app workloads. Production direction includes restricted privileges, limited capabilities, resource limits, and no direct Docker socket access for untrusted workloads. Only controls that are enforced in production should be treated as guarantees.

Runex is progressing toward clearer network boundaries between projects so one customer’s deployment cannot freely reach another customer’s private services. Deeper project-level network policies are an architecture direction — mark them as roadmap until fully enforced.

Where databases are provided or attached, isolation should be scoped by project/application. Do not assume cross-project database access is available or desirable.

Runex provides HTTPS for deployed applications on *.runex.cloud and for custom domains connected through cname.runex.cloud. We describe HTTPS as a concrete control — not “military-grade encryption.”

Secrets and environment variables should be injected server-side/runtime-side — never embedded in public HTML, client JavaScript, or public repositories. Documented secret-rotation and visibility behavior will match what the dashboard actually implements.

Deployment webhooks from GitHub are verified so automated redeploys are tied to authenticated GitHub events rather than arbitrary unauthenticated requests.

Builds should run in controlled environments separate from unrelated customer runtimes. Exact build sandbox details evolve with the platform; we avoid overstating them here.

CPU, memory, and related limits protect the host and reduce the risk that one deployment consumes resources needed by others.

Access to deploy and manage applications is gated by authenticated Runex accounts and GitHub App permissions for repository access.

Deployment status and logs help operators understand build/runtime failures. Platform-level monitoring continues to deepen; we do not publish unverified SLAs.

Runex does not claim SOC 2, ISO 27001, PCI DSS, HIPAA, or similar certifications on this page. If formal certifications are obtained later, they will be listed here with accurate scope.

If you believe you have found a security issue in Runex, contact the team through the channels published on runex.cloud / about. Please avoid posting exploit details publicly before coordinated disclosure.