Security & network

This page is for corporate IT and security reviewers. It only describes what is implemented today. Deployment Playbook does not currently hold certifications (such as SOC 2 or ISO 27001) and does not publish an uptime SLA.

Allow-list

Domains the browser needs

Domain Why
deployment-playbook.com The app, its API and all static assets (fonts and scripts are self-hosted; no CDN, font or analytics third parties are loaded).
accounts.google.com Sign in with Google (only if you use it).
github.com Sign in with GitHub (only if you use it).
login.microsoftonline.com Sign in with Microsoft (only if you use it).
Your own identity provider SAML or OIDC single sign-on, if your workspace configures it.
checkout.stripe.com, billing.stripe.com Paid plans: Stripe Checkout and the Stripe customer portal (Admins only).

Endpoints your CI/CD and tools call

All on https://deployment-playbook.com, authenticated with a workspace API token (Authorization: Bearer …):

  • GET /api/gate/<planId> - pipeline gate (see API).
  • POST /api/plans - create a plan from CI.
  • /api/mcp - remote MCP server for AI assistants (read and create; never approve).
  • /api/hooks/<provider> - incoming provider events, verified with a per-connection secret.
  • /api/integrations/github/webhook - GitHub App events, verified with the app webhook secret (X-Hub-Signature-256), de-duplicated by delivery id and rate-limited per installation.
  • /api/integrations/gitlab/webhook/<id> - GitLab tag-push and deployment events, verified with the connection's secret token (X-Gitlab-Token), de-duplicated and rate-limited.
  • /api/integrations/azure-devops/webhook/<id> and /api/integrations/azure-devops/check/<id> - Azure DevOps service hook and environment check, authenticated with the connection password (HTTP Basic), rate-limited; hook deliveries de-duplicated.

Outbound connections from the service to you

  • Status webhooks to the URL a workspace Admin configures, signed with HMAC-SHA256 (header X-Playbook-Signature-256, over timestamp.body). Redirects are not followed; 5-second timeout.
  • GitHub integration (only when a workspace installs the GitHub App): https://api.github.com (installation tokens, check runs, deployment protection rule answers, repository list) and https://github.com/login/oauth/access_token (one-time check during installation that the installing user can access the installation).
  • GitLab integration: only the GitLab URL a workspace Admin configures (https://gitlab.com or a self-managed instance over https on a public address): token check, commit statuses and deployment approvals.
  • Azure DevOps integration: only the organization URL a workspace Admin configures (https://dev.azure.com/<org> or Azure DevOps Server over https on a public address): token check, tag lookup, Git statuses, and the check callback (TaskCompleted) to that same organization.
  • SSO: the server fetches your OIDC discovery document, JWKS and token endpoint, or your SAML metadata URL.
  • SSRF protection: these URLs must be https; host names are resolved and requests to loopback, private, link-local, CGNAT, cloud-metadata, IPv6 unique-local and other reserved ranges are refused, both when the URL is saved and when the request is made (the checked address is the one connected to).
  • Source IPs are not fixed. The service runs on managed AWS infrastructure without a static egress IP, so allow-listing by IP is not possible; verify webhook signatures instead.

Email

Email (verification links, invitations) is sent from no-reply@deployment-playbook.com through Amazon SES (eu-central-1). Messages are DKIM-signed for deployment-playbook.com, use the custom MAIL FROM domain mail.deployment-playbook.com with an SPF record for Amazon SES, and the domain publishes a DMARC record.

Hosting & data residency

  • Hosting: AWS Amplify and Amazon Aurora PostgreSQL in AWS eu-central-1 (Frankfurt, Germany). The database is encrypted at rest and has automated backups.
  • Processor: Generation Y B.V. (Breda, the Netherlands).
  • Subprocessors: Amazon Web Services EMEA SARL (hosting, database) and Stripe Payments Europe Ltd. (billing). The authoritative list, transfers and notice periods are in the Data Processing Agreement and the Privacy Policy.
  • Retention, per the Privacy Policy: account and workspace data for the duration of the agreement, then a 30-day export window and deletion within a further 30 days; backups expire automatically within 35 days; server/security logs at most 90 days; billing records 7 years (Dutch fiscal obligation).

Security controls

  • Transport: the service is served over HTTPS only, with HSTS (max-age=63072000; includeSubDomains).
  • Browser security headers: Content-Security-Policy (no third-party script hosts, frame-ancestors 'none'), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and a restrictive Permissions-Policy.
  • Tenant isolation: every query is scoped to a workspace; API tokens only see their own workspace and unknown or foreign plan ids return 404.
  • Passwords: bcrypt (cost 12). Changing your password signs out your other sessions.
  • Password reset: emailed single-use links valid for 1 hour, stored only as hashes, with a cooldown; the response never reveals whether an account exists, and a reset signs out every session and is recorded in the audit log.
  • Rate limiting: failed sign-ins are limited per email address (10 per 15 minutes) and per IP address, with increasing delays; sign-ups, verification emails and password-reset requests are rate-limited too. Errors are generic.
  • Sessions: random 256-bit tokens, stored only as SHA-256 hashes, in an HttpOnly, Secure, SameSite=Lax cookie, valid 14 days.
  • Email verification: password sign-ups confirm their address through a single-use link (24 hours, stored as a hash) before they can create or join a workspace. Resends are rate-limited.
  • Social login and SSO: Google, GitHub and Microsoft sign-in; SAML 2.0 and OIDC single sign-on per workspace with state, PKCE and nonce, signature checks on id_tokens and SAML assertions, DNS-verified domains and optional SSO enforcement with a break-glass Admin. See SSO and social login.
  • Roles: Viewer, Approver, Template manager and Admin. Only Approvers approve; Admins cannot approve unless they are also Approvers.
  • Four-eyes approvals: steps marked four-eyes need two different approvers, and nobody can approve their own proposal or evidence. Required steps can't be skipped.
  • Gate fails closed: errors and unknown plans return allow: false.
  • API tokens: per workspace, shown once, stored as SHA-256 hashes, revocable, last use recorded. They can create and read plans and check gates, but never approve.
  • Secrets at rest: webhook signing secrets, provider-connection secrets and OIDC client secrets are encrypted with AES-256-GCM and never shown again after saving.
  • Payments: card data is handled by Stripe; Stripe webhooks are verified with Stripe signatures.
  • Audit log: plan and step decisions, template changes, members and roles, tokens, webhooks, SSO configuration and SSO sign-ins.

Responsible disclosure

Found a vulnerability? Email info@genydev.nl with steps to reproduce. Please give us reasonable time to fix it before disclosing it publicly. See also /.well-known/security.txt.