Security at djustlive

Untrusted code, by default. Sealed, by design.

djustlive runs Django apps for many customers on shared infrastructure. We assume any tenant could be hostile, and we build the platform to that assumption. This page describes what that gets you.

01Isolation

Each customer app runs in its own sealed environment with hardware-backed process boundaries. Code in one app cannot read memory, files, or network traffic belonging to another — even if it tries.

02Least privilege

Your code starts with no special privileges. Capabilities the host kernel grants by default are dropped before tenant code is reached, and they cannot be restored. The runtime your app sees is intentionally narrow.

03Operational rigor

Every deploy is logged. Every credential is scoped to one project, one deployment, one purpose. Operators have access to platform internals, not to customer code or memory.

What this means in practice

Concrete properties of the runtime your app sees, and the platform around it. We don't ship features that contradict this list.

✓
Hardware-backed app isolation Each app runs in its own boundary, not just a shared OS namespace.
✓
Privilege drop before tenant code By the time your code starts, the runtime cannot escalate.
✓
Outbound network restricted by default Apps reach the services they need, not the open internet, unless you opt in.
✓
Read-only application image Tenants can't tamper with the framework or system binaries at runtime.
✓
No shell in the runtime An attacker who pops Python lands in a system without a shell to pivot from.
✓
Resource limits enforced at the platform level One runaway tenant can't starve your app of CPU or memory.
✓
Per-deployment scoped credentials Tokens used by your app are valid for one project, one deployment, and revoked at the next deploy.
✓
Database isolation per project Schema or instance separation; never a shared connection across tenants.
✓
TLS for everything public Auto-renewed certificates on default and custom domains. HTTP redirects to HTTPS.
✓
Webhook integrity checked at the boundary HMAC-validated signatures from GitHub and GitLab; failed signatures never reach the build queue.

Authentication options

  • Email + password with rate-limited login
  • GitHub and Google OAuth via standardized flows
  • Two-factor authentication for accounts that turn it on
  • Per-user, revocable API tokens for the deploy CLI
  • djustlive itself can act as an OAuth/OIDC provider for first-party tooling

Vulnerability disclosure

We work with security researchers in good faith. Send a clear reproduction, give us a reasonable window to ship a fix, and we'll acknowledge promptly and credit you publicly if you'd like.

For high-severity issues we aim to acknowledge within two business days and ship a fix or compensating control within thirty days.

Please don't run live exploit attempts against production. Set up a free-tier project and test against your own deployment first.

Report to security@djustlive.com

GitHub private security advisories on the djustlive repository are also accepted. PGP key available on request.

The platform should make it boring to run untrusted code. Surprises belong in product, not in security.
— djustlive engineering