Moving to self-hosting
Take what you evaluated on Eddytor Cloud into your own deployment - same images, your infrastructure.
Eddytor Cloud runs the identical public packages a self-hosted installation uses, so "moving" is less a migration than a redeployment: stand up your own instance and point it at the same object store.
Why your data doesn't need migrating
Your table data was never inside Eddytor Cloud - it lives in the bucket you connected (see How it works); only Cloud's metadata (organisation membership, roles, API keys, policies, audit history) is re-created on your own instance.
Steps
Deploy Eddytor. Quickest start on a single machine:
curl -fsSL https://get.eddytor.com | shor on Kubernetes with the Helm chart:
helm install eddytor oci://ghcr.io/nordalf/charts/eddytorSee Deploy for docker-compose, AKS/GKE/EKS guides, and the production checklist.
Create the first admin. Self-hosted instances have self-service sign-up disabled
by default; provision the first account with eddytoradm setup - see
First admin. Invite the rest of your team
from there.
Register the same storage. Add the bucket you used on Cloud (Connect Storage). Discovery finds your existing Delta tables; nothing needs to be exported or copied.
Re-create governance. Policies, workspaces, shared storage configurations, and API keys are metadata - re-create them via the REST API or CLI. Keys minted on Cloud will not work against your instance.
Clean up Cloud. Delete the storage configurations from your Cloud organisation so the hosted environment no longer holds credentials for your bucket.
What changes when you self-host
| Eddytor Cloud | Self-hosted | |
|---|---|---|
| Sign-up | Self-service, email confirmation | Disabled by default; eddytoradm setup + invites |
| Capacity | Shared, instance limits | Yours to size and configure |
| Upgrades | Managed for you | You choose when (Upgrades) |
| Features & API | Identical | Identical |
Good to know