Security Policy

1. Overview

This policy describes the technical and organizational measures Deployxa uses to protect the platform and the data you trust us with, and how to report a security issue. Deployxa does not currently hold third-party security certifications or audit reports; the controls below are what is in place today. Security is a shared responsibility: we secure the platform, and you are responsible for the code you deploy, its dependencies, and who you give access to.

2. Infrastructure and isolation

• One container per app: every workload runs in its own Docker container with separate namespaces and CPU and memory limits, so one app cannot starve or read another.
• Private networking: containers sit on an isolated network. Only the TLS-terminating edge proxy (Traefik) can reach them from the internet.
• Filtered system calls: system calls are filtered to block privilege escalation from inside a container.
• Separated control plane: account, project and deployment state lives in PostgreSQL; builds and environment setup run as queued jobs (BullMQ on Redis), separate from the web tier.
• Backups: the platform database is snapshotted on a schedule and monitored.

3. Encryption

• In transit: the dashboard, API and every app route are served over HTTPS. TLS certificates are issued and renewed automatically by Let’s Encrypt through Traefik.
• At rest: environment variables and secrets are stored encrypted.
• Webhooks: Git push webhooks are verified with SHA-256 signatures before a build is triggered.

4. Secrets handling

• Environment variables are encrypted at rest, decrypted only when injected into your container at start-up, and never written to build logs.
• Repository access tokens are kept private and used only to fetch code and receive webhooks for repositories you authorize.
• Sign-in tokens in the dashboard are held in session storage, not persistent local storage, and are cleared when you sign out or close the tab.
• Card numbers are entered on our payment processors’ checkout pages and are never stored by Deployxa.
• Your responsibility: do not commit secrets to your repository or bake them into images. Use environment variables, and rotate any secret you believe has been exposed.

5. Access control and RBAC

• Team roles: Owner, Admin, Developer and Viewer roles scope who can deploy, edit secrets, manage members and manage billing.
• API keys: create and revoke keys for the CLI and CI/CD from the dashboard instead of sharing passwords.
• Sign-in: email and password, or Google sign-in.
• Internal access: Deployxa staff access production systems and customer data only when needed to operate, support or secure the service, on a least-privilege basis.

6. Logging and monitoring

• Security events, API key creations and rotations, and member invitations are recorded in your organization’s audit log.
• Build, deployment and container logs are available to you in the dashboard and kept on your plan’s retention schedule.
• We monitor platform health and logs to detect abuse, failures and suspicious activity.
• Logs are designed not to contain secrets; environment variable values are never written to build output.

7. Incident response

When we detect or are told about a security incident we:

1. contain it, for example by isolating affected containers, revoking credentials or blocking traffic;
2. investigate its cause and scope, and preserve relevant logs;
3. fix the underlying issue and restore normal service;
4. notify affected customers without undue delay, and in any case in line with our Data Processing Agreement and applicable law; and
5. review what happened and improve our controls.

8. Vulnerability disclosure

We welcome reports from security researchers. Email [email protected] with:

• the affected URL, endpoint or component;
• steps to reproduce, with a proof of concept if you have one; and
• the impact you observed.

When testing, please:

• only test against accounts and apps you own or have permission to test;
• do not access, change or delete other customers’ data, and stop as soon as you reach data that is not yours;
• do not run denial-of-service, spam or social-engineering tests, or test physical security; and
• give us a reasonable time to fix the issue before disclosing it publicly.

We will acknowledge your report, keep you updated on our progress, and credit you if you wish. We will not pursue legal action against researchers who act in good faith and follow these guidelines. We do not currently run a paid bug bounty programme.

9. Your responsibilities

• Keep your dependencies and base images up to date and patch vulnerabilities in your own code.
• Use team roles to give members only the access they need, and remove people who leave.
• Protect your account with a strong, unique password and revoke unused API keys.
• Follow the Acceptable Use Policy.

Questions about this document? Email [email protected].