Security & Isolation

Pywa Cloud runs every bot in its own Docker container on a shared host. This page describes exactly what that does and doesn’t protect against, so you can decide whether it’s the right fit for what you’re deploying — not as a marketing claim.

What isolates your container

• A dedicated Docker network per bot. Your container is never on Docker’s shared default network with any other tenant’s — it has its own network with nothing else attached to it. Verified directly, not just asserted: two real containers on two real networks genuinely cannot reach each other, even by raw IP, because separate Docker bridge networks have no route between them by default.
• Runs as a non-root user inside the container, with every Linux capability dropped (--cap-drop ALL) and privilege escalation disabled (--security-opt no-new-privileges) — your code has no capability it would need root or a specific capability for, and can’t acquire one.
• A read-only root filesystem, with a small, size-capped, memory-backed scratch directory at /tmp for incidental writes (e.g. a media attachment downloaded from the WhatsApp Graph API before you process it). Nothing your code writes anywhere survives a redeploy or restart, and nothing it writes can fill the host’s disk.
• CPU, memory, and process-count limits, applied identically at build time and run time — one runaway or malicious process can’t starve the host or other tenants’ containers of CPU, memory, or process table slots.
• No access to the Docker socket, the host filesystem, or the host’s process namespace, ever — neither your running container nor the ephemeral container used to validate your bot at build time. Your code cannot start other containers, see other tenants’ processes, or read the host’s files.
• A build timeout (default 10 minutes, PYWA_CLOUD_BUILD_TIMEOUT_S) and a maximum upload size (50MB) — a build that hangs or an oversized upload fails cleanly instead of consuming resources indefinitely.

What this deliberately does not claim

• This is container isolation, not VM isolation. Every tenant’s container shares the same Linux kernel on the same host. Docker’s isolation (namespaces, cgroups, the hardening above) is a real, meaningful boundary, but it is not the same guarantee a hypervisor-level VM boundary provides. If your threat model specifically requires VM-level isolation, this platform’s current architecture does not provide it.
• Outbound traffic shares one IP. Every bot on a given host currently sends outbound requests (including to Meta’s Graph API) from that host’s one public IP — there is no per-tenant egress IP or outbound traffic isolation yet. If your own security requirements need a dedicated egress IP, this isn’t there yet.
• One VPS. The MVP architecture is intentionally one control plane, one Docker host, one PostgreSQL instance — not a multi-region or highly-available deployment. See Production limitations below.

Reporting abuse

Every bot’s outbound traffic currently leaves through one shared VPS IP (see above) - if you believe a bot hosted on Pywa Cloud is sending spam, scraping, attacking a service, or otherwise behaving abusively, email [email protected] with what you’re seeing (source IP/timestamps if you have them, and what the traffic looked like). Reports are the primary way a specific bad actor gets found and stopped without penalizing every other tenant sharing that IP - the operator’s own process for what happens after a report arrives is documented in the control plane’s own README (“Operational runbook: handling an abuse report”).

Production limitations

This is an early-stage platform. Being direct about what that means in practice:

• No independent security audit or penetration test has been performed. The hardening described above reflects what the code actually does, reviewed by the team building it — not a third-party assessment.
• Admin operations currently use a single shared operator credential, not per-person accounts. This is adequate for a single operator; if you’re evaluating this platform as an organization with multiple support/ops staff, ask about the current state of this before relying on per-admin audit trails.
• No independent per-tenant network egress control, outbound rate limiting, or abuse-detection system beyond basic per-tenant ingress rate limiting exists yet.
• Backups exist and have been tested, but only against this codebase’s own schema in isolation — a specific production deployment’s own backup/restore procedure should be tested against that deployment’s real data before being relied on, not assumed to work because the mechanism has been tested elsewhere.

If any of the above is a blocker for your use case, ask before deploying anything sensitive — this page will be updated as the architecture changes, not left to go stale while the platform evolves.