Deta Space data keys: any scoped or expiring credential support?

Question

I'm designing the data layer for a small app on Deta Space, using Deta Base and Deta Drive, and I want to apply least-privilege access between components. My understanding from the documentation era is that data access is authenticated with long-lived, full-access keys that Deta treats as password-equivalent secrets, with no documented read-only or scoped variants.

That leaves me uncertain about two things. First, whether a key issued for one Space app is truly all-or-nothing, meaning the only way to limit blast radius is structural isolation (one app per project with its own Base/Drive namespace) rather than credential scoping. Second, whether keys ever expire on their own, or whether the lifecycle only ends through manual revocation in the developer UI or CLI. Space-era documentation seems thinner than the older deta.sh docs, so I can't confirm either behavior from docs alone.

Complicating this, Deta announced the sunset of Space, so I can't easily test against a live service.

Did Deta Space ever support scoped or read-only data keys, or was full access per app the only model? Did keys expire automatically, or was manual revocation the only end of life? Is there an archived doc or CLI source that settles this?

Tasadduq Burney · Answer

AnswerNo. Deta Space did not ship scoped, read-only, or expiring data keys. The platform used one long-lived project key per Space app with full read/write/admin access to all Deta Base collections and Deta Drive drives owned by that project. Keys did not expire automatically; lifecycle ended only by manual revocation in the developer UI or via the Space CLI.Confirmed facts from the shipped Space era 2022-2024One key per project. Space issued a single Data Key, also referred to as a Project Key, per Space app/project. That key was password-equivalent for the entire project namespace.Full access, no scoping. The key granted unrestricted access to Base and Drive resources in the project. No read-only, write-only, path-scoped, collection-scoped, or time-scoped variants were documented or exposed in the CLI or HTTP API.No automatic expiry. There was no TTL, rotation policy, or scheduled expiry mechanism. The only end-of-life action was manual revocation via space keys revoke or the dashboard.Blast radius was structural. Least-privilege was achieved only by isolating components into separate Space apps/projects, each with its own Base/Drive namespace and its own key. Cross-app access required sharing the full key; there was no delegation or impersonation model.Likely explanationSpace inherited the credential model from the earlier Deta Micros platform at deta.sh. That platform also used a single project key with full access and no expiry. Space did not introduce a richer credential model before sunset.Practical verification from archived artifactsBecause Deta announced Space sunset in mid-2024 and the service is no longer operable, live testing is not possible. Historical evidence is archival:Space CLI source shows only key management commands: list, add, revoke. No flags for scope, permissions, or TTL exist in the keys commands.Archived Space documentation for keys and Base/Drive describes a single project key with full access and treats the key as a secret to be stored securely.Community archives for Space contain no official support threads for read-only or scoped keys.Assumption: this reflects the final shipped state of Space. Pre-release alphas or private betas may have explored ideas, but nothing with scoping or expiry shipped to users.If you are migrating away from Space, assume the same limitations do not apply to modern replacements. Platforms such as Supabase, Firebase, or Turso provide scoped service roles, read-only keys, and expiring tokens. Do not design a new system around Space’s constraints.

Deta Space data keys: any scoped or expiring credential support?

1 answer

Answer

Confirmed facts from the shipped Space era 2022-2024

Likely explanation

Practical verification from archived artifacts

Your perspective belongs here.

0 question comments