Most teams should not self-host their DAM — and some teams absolutely should. That's the honest version of this guide in one sentence. Self-hosting means running the software on infrastructure you control: your servers, your database, your storage, your rules. It trades convenience for control, and whether that trade makes sense depends on constraints that are usually decided outside the marketing department.

freedam is built to run both ways — as a hosted service and as a self-hosted deployment of the same product, fully dockerized, with nothing held back. This guide covers why organizations choose to self-host, what you're actually signing up for operationally, what a deployment looks like in practice, and how to make the call.

Why organizations self-host

The reasons cluster into a few recurring patterns, and it's worth knowing which one is yours, because they lead to different requirements.

Data protection and privacy law. Your asset library contains more personal data than most teams realize: event photography full of identifiable people, model releases, consent records, employee headshots — and if you use face recognition, biometric-adjacent data with its own legal weight. For organizations under strict data-protection regimes, or with works councils and data-protection officers who must sign off on processing locations, "the data never leaves our infrastructure" is the sentence that ends a six-month review early. Self-hosting makes it literally true.

Sovereignty and jurisdiction. Public-sector bodies, healthcare, defense-adjacent industries, and organizations in jurisdictions with data-residency laws often can't put certain data on infrastructure operated by a foreign company — regardless of where the servers physically sit, because the operator's legal exposure matters, not just geography. Self-hosting removes the operator from the equation.

Contractual constraints. Sometimes the constraint isn't yours. Agencies and studios inherit their clients' security requirements; a single enterprise client's vendor-security addendum ("no client material on third-party processors without prior written approval, per-subprocessor") can make self-hosting the cheapest path to compliance across your whole client roster.

Network topology. If the DAM must sit close to something — a render farm, a studio's 10-gig LAN where editors pull hundred-gigabyte video masters, an air-gapped environment — hosting it yourself puts it where the bytes are.

Institutional preference. Some organizations simply run their own systems as policy, have the ops team to do it, and see a self-hostable product as the only kind they'll adopt. That's a valid reason too; it just shouldn't be the only reason if none of the above apply, because the costs below are real.

Notice what's not on the list: saving money. Self-hosting can be cheaper at scale, but hardware, storage, and — above all — operator attention are real costs. If your motivation is purely budget, do the arithmetic in the "tradeoffs" section first.

What you take responsibility for

When you self-host, you become the operator. The software is the same; the pager is now yours. Concretely:

Infrastructure. Provisioning and maintaining the host(s), the OS, Docker, TLS certificates, DNS, and whatever sits in front (reverse proxy, firewall, VPN or tunnel). Disk capacity planning deserves special respect: asset libraries only grow, and previews, derivatives, and search indexes grow alongside the originals.

Backups — and restores. The database and the asset storage need independent, tested backup strategies. The word that matters is tested: a backup you've never restored is a hypothesis. Asset originals are irreplaceable in a way application servers aren't; treat object storage with versioning or offsite replication as non-negotiable.

Updates. The application, its containers, the OS, and the database all need updating on your schedule. Hosted users receive updates continuously; self-hosters who defer updates for a year get to do one big, riskier migration instead of many small ones. Budget a regular maintenance window and actually use it.

Security. Perimeter (ideally the instance isn't naked on the public internet — an outbound tunnel or VPN keeps ports closed), secrets management, OS hardening, and monitoring. The application handles authentication, per-asset access rules, and audit trails; everything below the application is yours.

Monitoring and capacity. Disk usage, queue depth, database health, certificate expiry. Most self-hosted incidents are not exotic — they're full disks and expired certificates, both preventable with basic alerting.

None of this is heroic — it's the standard operational hygiene of any self-run web application. But it's recurring work for a person who exists. The honest minimum is a team (or a committed individual) comfortable with Docker, Linux, and PostgreSQL, with a few hours a month of steady-state attention. If nobody in your organization runs anything today, hosted is the right answer, full stop.

What a dockerized deployment looks like

A modern DAM is not one program; it's a small fleet of cooperating services. freedam ships this fleet as a Docker Compose deployment, which is what makes self-hosting tractable: the entire topology is declared in configuration files, and one command brings it up.

What's actually in the fleet, and why:

• The application and web tier — the PHP application served behind nginx. This is the part users see.
• PostgreSQL — the database, extended with vector similarity and full-text search extensions. This is what powers semantic and visual search without any external search service: embeddings and text indexes live in the same database you're already backing up.
• Redis — caching and queue transport.
• Queue workers — several, deliberately separated by workload: fast jobs (ingestion, metadata), CPU-heavy work (preview and thumbnail generation, document conversion), and long-running I/O-bound work (AI analysis, transcription, face detection). Separation means a batch of thousand-page PDFs can't starve the queue that makes your uploads appear.
• A virus-scanning daemon (ClamAV) — every incoming file is scanned before it enters the library.
• Supporting sidecars — document-to-PDF conversion, a local embedding service for search, face detection. Optional AI capabilities can run against local services or external providers, depending on how strict your "nothing leaves" requirement is.
• Object storage — asset originals belong on S3-compatible storage, which you can also self-host or source from a provider in your jurisdiction.

The practical rhythm: clone, set environment configuration, docker compose up, run migrations, create the first tenant. Updates are the same shape — pull, rebuild, migrate. Because every service is a container with a declared role, your ops team can reason about it with the tools they already use, and nothing about the deployment is secret sauce: the product's self-hosting page and repository document the full topology.

One architectural note worth knowing before you size hardware: the heavy lifting in a DAM happens asynchronously. Uploads return quickly; previews, AI tagging, transcription, and indexing happen in background queues. That's why worker capacity, not web capacity, is what you scale as the library grows.

Sizing basics

Precise sizing depends on your media mix, but the shape of the answer is consistent:

Start with one capable machine. A single host with 8 cores, 32 GB of RAM, and fast SSD storage comfortably runs the full stack for a team-sized library (tens of thousands of assets). This is the right starting point for almost everyone; distributed deployments are something you grow into, not start with.

Storage is the real variable. Estimate it from your originals: current library size, plus expected intake per year, plus roughly 20–40% overhead for previews and derivatives, plus database and index growth. Video changes everything — a photo library measures in hundreds of gigabytes, a video library in tens of terabytes. Keeping originals on object storage decouples this from the application host, which is the main reason to do it.

CPU goes to previews and conversions. Ingesting large batches — a migration, a shoot delivery — is when you'll notice cores. More worker CPU shortens the window between "uploaded" and "fully processed"; it doesn't affect day-to-day browsing.

RAM goes to PostgreSQL. Search quality is index-driven, and indexes want memory. If you must choose where extra RAM goes, the database wins.

AI needs a decision, not necessarily a GPU. Embeddings for semantic search run on CPU acceptably. Heavier AI enrichment can be routed to external providers when your policy allows, or kept local when it doesn't — with local inference costing you hardware in exchange for isolation.

When one machine stops being enough, the compose topology already separates concerns, so the growth path is unexciting: move the database out, move workers out, scale storage independently. Unexciting is what you want.

The honest tradeoffs

Same product, two operating models — here is what actually differs:

Where hosted wins. Zero operational load; continuous updates with no maintenance windows you schedule; infrastructure, backups, and monitoring handled by the people who built the system; failures are someone else's 3 a.m. The total cost is a predictable subscription, and the time-to-running is minutes.

Where self-hosting wins. Data location and jurisdiction are provably yours; security reviews simplify dramatically ("it's inside our perimeter" answers whole questionnaires); no per-seat or per-asset meter changes the economics of scale; you control the upgrade calendar; the system can live inside networks a hosted service can't reach. And with an open, self-hostable product there's a structural benefit that outlasts any contract: you can never be locked out of your own library. The deployment you run today keeps running regardless of any vendor relationship.

Where self-hosting costs you. Every operational responsibility in the list above, forever. Updates arrive when you apply them, not when they ship. Your recovery time in an incident is set by your own runbooks. And the true cost comparison must price your operator's hours honestly — a few hours a month of a capable engineer is not free, and during migrations or incidents it's more than a few.

A useful heuristic: hosted by default; self-hosted when a named constraint demands it. If you can write down the constraint — the regulation, the clause, the network — self-host with confidence; the operational cost is the price of meeting a real requirement. If you can't write it down, you're paying that cost for a preference.

A middle path exists, too: start hosted to validate the workflows, taxonomy, and adoption with zero ops investment, and move in-house when the constraint materializes. Because it's the same product, metadata schemas, vocabularies, and workflows carry over — the migration is data movement, not a re-implementation.

Making the call

1. Name the constraint. Regulation, contract, network, or policy — in writing. No constraint, no self-hosting.
2. Name the operator. A person or team who runs Linux/Docker/PostgreSQL today and accepts the pager.
3. Size storage first, compute second. Storage is the number that grows.
4. Prove the restore before go-live: restore a database backup and a storage backup onto a clean machine, end to end.
5. Schedule updates as routine maintenance from day one — monthly is a good default.

Get those five right and self-hosting a DAM is well-trodden ground, not an adventure.

---

Ready to look at the deployment itself? See self-hosting for the full picture, or try the hosted demo first — it's the same product either way.