Shared storage configurations
Make a storage connection available to a whole workspace - by registering into it or promoting a personal config.
A storage configuration is owned either by you (personal) or by one workspace (shared) - never both, never several workspaces. Sharing with the whole organisation is done by sharing into the default workspace, which every member can use.
Managing workspace-owned storage requires the storage_configs:share scope and an
Admin or Builder position in the target workspace.
Two ways to share
Register directly into a workspace - pass workspaceId when you
connect storage:
eddytor create storage s3 ... --workspace <workspace-id>Promote an existing personal config:
eddytor promote storage <config-id> --workspace <workspace-id>The configuration's id is stable across promotion, so its catalog schema
(cfg_<id>) and every registered table keep resolving - queries and saved names
don't break.
Undo window
Promotion can be reverted by the person who promoted it, within 15 minutes:
eddytor promote storage <config-id> --undoAfter the window closes, the only teardown path is deleting the configuration. Promoting an already-shared config to a different workspace re-attaches it (requires Admin/Builder on both sides) and extinguishes any pending undo.
What a share actually grants
The promote response and the CLI tell you which of two things happened:
sharesStoredCredential | Meaning |
|---|---|
true | The config carries a stored secret (access key, SAS, service principal, GCS key). Every workspace member now reads the bucket with that credential's access. |
false | The config is a pointer using delegated provider access (delegatedProvider: azure or google). Each member authenticates as themselves and needs their own provider link and their own IAM access - members without one see the config listed with no tables under it. |
Heads up
Ownership
Workspace configs survive their creator: if the person who shared a config leaves or is deleted, the config and its secret remain owned by the workspace. Changes take effect immediately - member changes, promotes, re-attaches, and undos drop affected engine sessions.
Audit trail
storage.config_promoted, storage.config_promote_undone, and
storage.config_reattached events land in the
audit log.
See the Storages API reference for the underlying endpoints.