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.

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> --undo

After the window closes, sharing is one-way by design - the 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.

The promote response - and the CLI - tell you which of two very different things just 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

Promoting a config with a stored credential is an access grant to everyone in the workspace, present and future. For the org-wide default workspace, that means the whole organisation.

Ownership details

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.
Listings show provenance: sharedBy carries the sharer's email (resolved even for members who can't read the member directory), undoAvailableUntil marks a live undo window, and accessStatus flags configs you can list but not use.
Updating or deleting a workspace-owned config requires storage_configs:share on top of the usual storage scopes.
Sharing takes effect immediately - member changes, promotes, re-attaches, and undos drop affected engine sessions so visibility never lags.

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.

Shared storage configurations

Two ways to share

Undo window

What a share actually grants

Ownership details

Audit trail

On this page