Security

Accounts

• Dekka has no passwords to steal or reuse. You sign in with a single-use email link that expires after 15 minutes, with GitHub or Google, or with a passkey.
• Your session lives in an HttpOnly cookie pinned to the dashboard's own origin, so code deployed on apps.dekka.cloud can't read it. A session ends after three days without use and after 30 days in any case, and you can sign out other sessions from Settings.
• Someone outside your organisation gets 404 for anything in it, and members only get what their role allows.

Secrets and keys

• Variables, connection credentials, registry tokens and staged variable values are encrypted at rest with AES-256-GCM.
• Secret values stay hidden in the dashboard and out of logs, each reveal is recorded, and sealed values are never shown again to anyone.
• API keys are stored as hashes and shown once. Each has scopes, can expire and can be revoked, and can never do more than the person who created it.
• Every change to services, connections, variables, domains, keys and billing is recorded in your organisation's Activity.

Workloads and data

• The dashboard and API never run infrastructure commands themselves. A separate engine does, through an authenticated, versioned interface, and its reports back to Dekka are signed.
• Databases and buckets can't be reached from the internet unless you turn on a database's TCP proxy, and every connected service gets its own credentials.
• Each service runs with the memory and vCPU limits in its settings.
• Webhooks from GitHub and Paystack are checked against their signatures before Dekka acts on them.
• HTTP request logs keep a salted hash of each client's IP address, never the address itself, and database queries run from the dashboard are read-only and recorded without their text.

Where your data lives explains which parts of the platform run in Ghana and what has been independently verified.

Report a problem

Email security@dekka.cloud, and we'll acknowledge it within two working days.