Storage and data platform
Four shapes of storage.
One decision about who can reach them.
Silo holds your organization's files, its object storage, its databases and its data lake in one place, under one permission model. Four vendors become one system, four bills become none, and there is no longer a question of which of them is the source of truth.
What it stores
One storage layer, in the four shapes an organization actually needs.
These are not four products behind one login. They share a permission model, an audit trail and a single account, so a file and the database row that references it are governed the same way.
- A cloud drive for people
- Folders your organization works out of, shared inside the org, with another organization, or publicly.
- Object storage S3-compatible
- Buckets your applications write to with the S3 client you already use, and a CDN in front of them when you need one.
- PostgreSQL databases provisioned
- Databases created for you, with credentials your applications connect with directly. No separate database provider to manage.
- A data lake with warehouses and pipelines
- Datasets, warehouses and pipelines, so analytical work happens over the same storage the operational apps write to.
Who can reach it
Access is decided once, in the console your organization already uses for it.
Fine-grained on every resource
Permission is set on the bucket, the dataset, the database and the folder — not on a product-wide role that has to be right for all of them at once.
Governed from Cortex or Orchestrator
An organization picks which of the two owns Silo authorization: Cortex if IT should hold it, Orchestrator if it belongs with the owners. Either way it is one console, and Silo is not a second place to re-administer the same people.
The same people as everywhere else
The employees, teams and cost centers you grant access to are the ones your organization defined for the platform. There is no Silo-specific user list to keep in step.
An audit trail that covers all four
Activity and audit logs read across drive, object storage, databases and lake together, because they are one system rather than four with four logs.
Your own applications
Silo is not only for the sharpnr apps.
Connect directly
Your services get bucket credentials and database connection strings from Silo and use them the way they would use any provider. Nothing about that path involves the rest of the platform.
One bill's worth of moving parts
The object store your application writes to, the database it reads, and the lake your analysts query are the same account with the same permissions — so an engineer adding storage is not also adding a vendor.
Nothing to stand up first
Silo comes with the platform. There is no procurement step, no migration, and no integration project between it and the apps your organization already runs — those apps are already storing here.
The rest of the platform
What Silo is already connected to
Silo is underneath most of the platform. When another sharpnr app stores something, it stores it here — which is why a file you can see in one app is a file you can already see in the others.
- Cortex and Orchestrator
- Whichever your organization uses to govern who can reach what — access to every Silo resource is decided there, not here.
- Folio
- Documents, sheets and canvases are stored in Silo, and any Silo object can be referenced from inside a document.
- Cables
- Files are searchable and shareable from inside any conversation, without leaving it to go find them.
- sharp-iam
- Employee and project documents live here, reachable from the portal the employee already uses.
- Stockwave
- Operational records and warehouse documents are stored alongside everything else the organization keeps.
One storage layer, already under your organization.
If your organization is on sharpnr, Silo is already holding what the other apps have written.
Already have a sharpnr account? Sign in.