Most of the long-term cost and risk of a DAM sits in where the files are kept. Before you commit, ask every vendor these three questions. Here is how ZDAM answers them.
With ZDAM, in the bucket you connect: your provider, your account, and the region you chose when you created it. The previews ZDAM generates are stored there too, next to the originals.
You do. The storage bill comes from your provider, to you, so you always know what storage costs and nothing is resold to you.
Nothing. They stay in your bucket exactly as they are. ZDAM does not move or delete them when you stop using it.
ZDAM is the management layer. Your bucket stays the place where the files live.
Step 1
Create a new, empty bucket with your provider and add its credentials in ZDAM. ZDAM lays out the bucket structure itself, validates the connection and audits its permissions before using it. It needs full read and write access to the bucket, and the credentials are encrypted with AES-256-GCM and masked in API responses.
Step 2
Upload into ZDAM and every file lands in your bucket. ZDAM generates previews and stores them in your bucket alongside the originals, so you get metadata, search, previews, watermarks and sharing on storage you own.
Step 3
Background workers check every connected source every 6 hours, and uploads are checked against your storage quota before they start, so a full bucket is caught early instead of failing midway.
You choose the provider and the region, and you hold the account. Your storage policies stay in your hands, at your provider, not inside a DAM vendor.
Your files never become hostage to the DAM. If you stop using ZDAM, everything you stored is still in your bucket, untouched.
Storage is billed to you by your provider, at the rates on your own account. There is no storage line hidden inside a DAM subscription.
Encrypted storage credentials, a dedicated database for every tenant, SAML 2.0 and OIDC single sign-on, MFA, and audit logging.
See how ZDAM handles securityConnect more than one source. Each runs as its own isolated workspace, and you can browse and search across all of them in one interface and move assets between them.
ZDAM offers full platform parity on every supported provider, so picking the storage that suits you does not mean giving up DAM features.
Connect any of these, with full platform parity on every one.
ZDAM can provision storage for you instead: Wasabi by default, or AWS S3 as a premium option, with a dedicated bucket for each tenant.
Wasabi, Amazon S3, Google Cloud Storage, ThinkOn, Backblaze B2, DigitalOcean Spaces, Cloudflare R2, and any other S3-compatible storage. ZDAM offers full platform parity on every provider.
Full read and write access. ZDAM stores your uploads and their previews in the bucket, so it needs to write as well as read. Credentials are encrypted with AES-256-GCM, validated with a permission audit when you connect, and masked in API responses.
In your bucket, alongside the original files.
Not today. ZDAM lays out the bucket structure itself, so it needs a new, empty bucket. Once your bucket and ZDAM tenant are live, your team uploads your existing files into ZDAM. Moving existing files in is the customer's responsibility, and we can help with bulk ingestion and scheduling. Support for buckets that already hold data is planned.
They stay in your bucket. ZDAM does not move or delete your files when you leave.
Your files stay with the provider and in the region you chose for your bucket. ZDAM itself, including the processing that creates previews, runs on AWS in us-east-1, its primary location.
Yes. Each connected source works as its own isolated workspace. You can browse and search across all of them from one interface and move assets between sources.
Book a demo and we will walk through connecting your storage, what ZDAM stores in your bucket, and how your team would work with it.