Infrastructure requirements

What this page covers

The exact requirements vary per package — what’s listed here is the foundation that every self-hosted VDF AI package builds on. For package-specific sizing, see the System requirements section on each package page.

Compute and memory

A self-hosted VDF AI package is delivered as a set of containers. Sizing depends on the package and the load.

Baseline — single-host development or proof-of-value

For a first deployment or a small-team pilot, a single capable host is enough:

Resource	Baseline
vCPU	4–8
Memory	16–32 GB
Storage	100 GB SSD
Network	100 Mbps egress for the initial image pull

A typical Linux VM in any major cloud, or a beefy on-prem box, sits comfortably in this range. This handles the full first-deployment walkthrough and is enough for a small team to try the product.

Production — small to mid-sized team

For an active team running real workloads:

Resource	Recommended
vCPU	16–32, distributed across nodes
Memory	64–128 GB
Storage	500 GB SSD plus snapshot policy
Network	Predictable 1 Gbps with low latency between nodes

Packages can be distributed across multiple nodes; the database tier should be on its own instance (or a managed service) for production.

Larger deployments

For larger user populations, heavier source corpora, or higher inference volumes, your sizing will be driven by usage patterns. Our team can help size — engage us via info@vdf.ai when you’re scoping a production rollout.

Supported operating systems

The packages are container images, so the host OS just needs a modern container runtime. Tested combinations:

• Linux — Ubuntu 20.04+, Debian 11+, Amazon Linux 2023, RHEL 8+, Rocky / Alma Linux 8+. Linux is the default target for production.
• Linux on Apple Silicon / ARM64 — fully supported; the images are multi-architecture.
• macOS — Docker Desktop works for local evaluation and developer environments. Not recommended for production.
• Windows — Docker Desktop with WSL 2 works for evaluation. Not recommended for production.

Container runtime

You need a current container runtime. Any of these work:

• Docker 24 or newer (24.x and 25.x are the most-tested versions).
• Podman 4 or newer.
• containerd (typically via Kubernetes).

The docker login and docker pull commands the portal generates are standard — they work with any OCI-compatible runtime.

Container orchestration

You can run a package three ways. Pick what fits your team’s operating model.

Database

Most packages need a relational database (PostgreSQL 16+) for persistence.

• Pilot / single host — the package’s recommended Docker Compose file includes a PostgreSQL container so you can be up and running in minutes.
• Production — point the package at a managed database (AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL, or your own clustered Postgres). The package’s install guide covers the connection-string handoff.

Plan for normal database operations: backups, snapshots, and a restore drill.

Network requirements

Outbound (initial pull)

• HTTPS access to the package registry. The portal-generated docker login and docker pull commands rely on outbound TLS to the registry endpoint shown in the credentials block. No inbound ports are required on your side.
• Optional: HTTPS to update channels if you want the package to know about newer versions automatically. Most operators prefer to pull updates on a deliberate cadence; either model works.

Internal (between services)

• Services within a package talk to each other over short-hop network. On Docker Compose that’s the default bridge network; on Kubernetes it’s intra-cluster.
• Recommended: keep cluster network policies restrictive — allow only what the package requires, deny everything else.

Ingress (for your users)

• Your users reach the package via the frontend service.
• You’ll typically front it with your own load balancer or reverse proxy (NGINX, Traefik, cloud LB) and your existing TLS termination.
• Most teams put the package behind their corporate SSO at the reverse proxy layer; the package itself also supports per-instance user accounts.

Air-gapped environments

If your environment has no outbound internet at all, you can still deploy. The pattern:

1. On a host with internet access, generate credentials in the portal.
2. Pull the package images to that staging host.
3. Push the images into your internal registry (Harbor, ECR-on-Outposts, Artifactory, whatever you run).
4. In your air-gapped environment, point the deploy at your internal registry.

This is a standard pattern; the install guide for each package covers it. Reach out to info@vdf.ai if you’d like us to walk through your specific setup.

Storage

Storage planning has three components:

• Container volumes — package state, user-uploaded content, cached artifacts. Sized in the package’s system requirements; plan 100 GB+ for production.
• Database storage — depends on usage; PostgreSQL sizing applies normally.
• Backups — snapshot strategy for the database and any persistent volumes. The exact cadence is yours to set, but daily is a sensible floor for production.

We strongly recommend SSD-backed storage. Spinning disk works for evaluation; production deployments on slow storage will feel sluggish even at modest load.

Certificates and TLS

The package frontend is typically fronted by your own reverse proxy. That’s where you’ll terminate TLS using whatever certificate authority your organization uses — corporate CA, public CA, or a private internal CA. The package doesn’t require any specific certificate vendor.

For service-to-service communication inside the package, the install guide covers what (if anything) needs to be tuned for your environment.

Identity and SSO

• Out of the box — packages ship with their own user account management.
• SSO — most production deployments front the package with an SSO-aware reverse proxy (SAML, OIDC, Entra/Okta). The package’s install guide covers the recommended pattern.

This is intentional: by terminating SSO at your edge, you stay in control of your identity provider relationship.

Secrets management

The package needs a small number of secrets (database password, signing keys, integration tokens for connected apps). Two patterns work:

• Environment file — the simplest model; suitable for single-host setups behind strict access controls.
• Your secrets manager — Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets backed by an external store. The install guide shows the mapping.

There are no VDF AI-specific secret formats; standard tooling applies.

Observability

The packages emit standard signals you can wire into your existing observability stack:

• Logs — written to stdout/stderr in standard JSON. Anything that scrapes container logs (Fluent Bit, Vector, Datadog, Cloud-native log routers) works.
• Health checks — each service exposes an HTTP health endpoint usable by load balancers and orchestrators.
• Metrics — Prometheus-compatible metrics endpoints; the install guide shows the names and paths.

You’re not locked into any specific vendor — point your existing tooling at the package and you’re done.

A pre-deploy checklist

Walk through this before you run the first docker compose up:

1. Target host or cluster is provisioned

   Compute, memory, and storage sized to the package's requirements.

2. Container runtime is installed and healthy

   docker info (or your equivalent) returns cleanly.

3. Outbound network to the registry is open

   Either to the public registry, or to your internal mirror for air-gapped setups.

4. Database plan is decided

   Bundled container for pilots, managed Postgres for production.

5. TLS and ingress plan is decided

   Reverse proxy, certificate source, hostname.

6. Secrets storage is decided

   .env file for pilots; secrets manager for production.

7. Observability plan is decided

   Where logs and metrics flow.

When all seven are green, your environment is ready. Pull the images and bring the package up.

What to read next

• Packages — the catalog and per-package system requirements.
• Getting started — the end-to-end first deployment walkthrough.
• Operations — running, updating, monitoring once you’re live.