Storage
Vidra's storage architecture has three layers: an Upload Path that ingests and validates incoming files, Primary Storage where transcoded files live (local disk or S3), and an optional Distributed tier (IPFS, WebTorrent) that reduces bandwidth and improves availability at scale. All three serving methods — direct HTTP, P2P, and IPFS gateway — can be active simultaneously.
Storage Architecture
Storage Backends
Primary Storage — Choose One
| Backend | Path / Config | Best for |
|---|---|---|
| Local Filesystem | ./data/storage/ (default) | Development, single-server deployments with sufficient disk |
| S3-Compatible | MinIO (self-hosted) or AWS S3 | Production deployments — scales independently of the API server, survives instance replacement |
Distributed Storage — Both Optional
| Backend | Purpose | When to enable |
|---|---|---|
| IPFS | Content-addressed pinning — files are replicated across the IPFS network | When you want P2P distribution or long-term content preservation |
| WebTorrent | P2P streaming from viewer to viewer | When you want to reduce origin bandwidth at scale (viewers help serve each other) |
When IPFS is enabled, the FFmpeg worker pins each transcoded file after upload and stores the resulting CIDs in PostgreSQL. If your IPFS node goes offline, the CIDs remain in the database and files are still served via direct HTTP from primary storage.
Integration Testing Ports
Integration tests run on a separate port range (19xxx) to avoid conflicting with the development Docker Compose services on their default ports.
| Service | Test Port | Default Dev Port |
|---|---|---|
| MinIO (S3) | 19100 | — |
| ATProto PDS | 19200 | — |
| ActivityPub Mock | 19300 | — |
| Mailpit | 19401 | 1025 |
| IOTA Node | 19500 | 14265 |
| PostgreSQL | 15432 | 5432 |
| Redis | 16379 | 6379 |
| IPFS | 15001 | 5001 |