Security specs

How Isoward isolates tenants on bare metal, not a black box. Customer apps on Isoward Cloud run in gVisor-warded containers with per-workspace bridges, host east-west DROP, SMTP lockout, and cgroup limits you can verify. Honest gaps stay in the security overview.

Outbound-only tunnel: your databases stay behind your firewall
Isoward Edge / DNS*.isoward.comCloudflare Tunnel (outbound only)Your private bare metalHome desktop / Hetzner / AWS VPC — your firewallIsoward gateway / runnerLocal sockets · host-header proxyOrchestrates Docker workloadsCustomer workloadsSandboxed gVisor · cgroup limitsPer-workspace networks

How isolation works

Skim the benefit, then expand for the system detail auditors need.

Warded workloads (gVisor)

Customer apps run under a userspace kernel that isolates them from the host.

On Isoward Cloud, customer app containers (web, static, workers, cron, private services) run under gVisor (runsc): a userspace kernel that isolates workloads from the host kernel. Self-hosted operators enable the same path with ./scripts/setup-gvisor.sh and ISOWARD_DOCKER_RUNTIME=runsc. Managed Postgres and Key Value stay on the default Docker runtime in this release.

Workload isolation

Per-plan cgroups and optional userns-remap keep noisy neighbors in check.

Every user-deployed application runs in a Docker container with per-plan cgroup CPU and memory limits. Resource bounds keep one workload from starving the host. With userns-remap enabled on the host (./scripts/setup-userns-remap.sh), customer container root maps to an unprivileged host user; the gateway uses userns_mode host so docker.sock still works.

Per-workspace networking + east-west DROP

iws-* bridges plus host firewall DROP so tenants cannot route to each other.

Each workspace gets its own Docker bridge with a short Linux iface name iws-* (com.docker.network.bridge.name). Absolute tenant isolation is host DOCKER-USER / ISOWARD-EASTWEST via ./scripts/setup-workspace-isolation.sh: DROP between iws-* bridges and customer↔customer hairpins on the shared edge network, while the gateway remains reachable. Soft Docker networks alone are not enough, and we say so.

SMTP egress lockout

Outbound 25/465/587 from customer containers are blocked on the host.

Outbound TCP ports 25, 465, and 587 from customer containers are blocked on the host with ./scripts/setup-smtp-egress-block.sh (DOCKER-USER DROP). CapDrop is hardening only; it is not the SMTP guarantee.

Edge encryption

HTTPS at the edge via Cloudflare Tunnel; no inbound 80/443 on the host.

Browser → Cloudflare is HTTPS (Universal SSL). Cloudflare → cloudflared is encrypted by the tunnel protocol. cloudflared → the gateway on the private Docker bridge is HTTP by design: you do not expose ports 80 or 443 on the host. Zone SSL mode is Full, not Full Strict: Strict expects a trusted TLS cert on the origin, which this tunnel architecture does not use.

Control and data plane

Gateway orchestrates; runtime executes. Honest about same-host packaging today.

The API gateway orchestrates deploys, auth, and routing. The runtime package builds and runs customer containers. Today that boundary is a package split on the same host, not a separate remote agent API.

Available today

  • gVisor (runsc) for customer app containers on Isoward Cloud
  • Same gVisor path for self-host when operators set ISOWARD_DOCKER_RUNTIME=runsc
  • userns-remap for customer containers when operators run ./scripts/setup-userns-remap.sh
  • Per-workspace Docker bridges with controlled iws-* Linux iface names
  • Host east-west isolation via ./scripts/setup-workspace-isolation.sh (ISOWARD-EASTWEST)
  • Host SMTP egress lockout via ./scripts/setup-smtp-egress-block.sh (25/465/587)
  • Per-plan CPU and memory cgroup limits
  • Audit logging for workspace actions
  • Session and API key authentication
  • Cloudflare Tunnel + edge TLS for *.isoward.com (no inbound 80/443 on the host)
  • Gateway host-header proxy to service containers
  • Control/data plane package separation (gateway orchestrates, runtime executes)
  • Global API rate limiting via @fastify/rate-limit on /v1 routes

Planned

  • Platform DDoS mitigation beyond Cloudflare at the edge
  • SAML SSO (OAuth providers available now)
  • Full RBAC enforcement on all routes
  • gVisor as the unconditional default on every self-hosted install
  • gVisor for managed Postgres / Key Value (apps only today)

Operator-managed

Self-hosted means you own the host perimeter. Absolute SMTP and east-west lockout are one-command host scripts, same ops model as gVisor and userns-remap.

  • Host firewall, OS patching, and disk encryption on your metal
  • Cloudflare account, tunnel credentials, and DNS for custom domains
  • SMTP egress lockout: run ./scripts/setup-smtp-egress-block.sh on the host
  • East-west isolation: run ./scripts/setup-workspace-isolation.sh on the host
  • userns-remap: run ./scripts/setup-userns-remap.sh on each host (gateway stays userns_mode host)
  • On self-host: install runsc (./scripts/setup-gvisor.sh) before enabling ISOWARD_DOCKER_RUNTIME=runsc
Read security docsEnable east-west isolation

Run it on your metal

Same UX on Isoward Cloud (gVisor on) or self-host with warded workloads when you enable runsc.

Deploy on our cloudInstall on your host