Self-Managed infrastructure requirements

Infrastructure and software requirements for W&B Self-Managed deployments

This page describes the infrastructure and software requirements for deploying W&B Self-Managed. It’s intended for platform and infrastructure engineers planning a Self-Managed installation. Review these requirements before you begin your deployment to confirm that your environment can support W&B Server.

W&B recommends fully managed deployment options such as W&B Multi-tenant Cloud or W&B Dedicated Cloud deployment types. W&B fully managed services are straightforward and secure to use, and require minimal to no configuration.

For complete architectural guidance, see the reference architecture.

Software version requirements

Software	Minimum version
Kubernetes	v1.32 or newer (Supported Kubernetes versions)
Helm	v3.x
MySQL	v8.0.x is required, v8.0.32 or newer; v8.0.44 or newer is recommended. Aurora MySQL 3.x releases, must be v3.05.2 or newer
Redis	v7.x

Hardware requirements

CPU Architecture: W&B runs on Intel (x86) CPU architecture only. ARM is not supported.

Sizing: For CPU, memory, and disk sizing recommendations for Kubernetes nodes and MySQL, see the Sizing section in the reference architecture. Requirements vary based on whether you’re running Models, Weave, or both.

For detailed sizing recommendations based on your use case (Models only, Weave only, or both), see the reference architecture sizing section.

Kubernetes

W&B Server is deployed as a Kubernetes Operator that manages multiple pods. Your Kubernetes cluster must meet the following requirements:

• Version: See the preceding Software version requirements section.
• Ingress controller: A fully configured and functioning ingress controller (Nginx, Istio, Traefik, or cloud provider ingress).
• Persistent volumes: Capability to provision persistent volumes.
• CPU architecture: Intel or AMD 64-bit (ARM is not supported).

W&B supports deployment on OpenShift Kubernetes clusters in cloud, on-premises, and air-gapped environments. For specific configuration instructions, see the OpenShift section in the Operator guide.

For complete Kubernetes requirements, including load balancer and ingress configuration, see the reference architecture Kubernetes section.

MySQL database

W&B requires an external MySQL database.

For production, W&B strongly recommends using managed database services:

• AWS RDS Aurora MySQL
• Google Cloud SQL for MySQL
• Azure Database for MySQL

Managed database services provide automated backups, monitoring, high availability, patching, and reduce operational overhead.

See the reference architecture for complete MySQL requirements, including sizing recommendations and configuration parameters. For database creation SQL, see the bare-metal guide. For questions about your deployment’s database configuration, contact support or your AISE.

W&B recommends using managed database services such as AWS RDS Aurora MySQL, Google Cloud SQL for MySQL, or Azure Database for MySQL for production deployments. Managed services provide automated backups, monitoring, high availability, and patching, and they reduce operational complexity.

MySQL configuration parameters

If you’re running your own MySQL instance, configure MySQL with the following settings for compatibility with W&B Server:

binlog_format = 'ROW'
binlog_row_image = 'MINIMAL'
innodb_flush_log_at_trx_commit = 1
innodb_online_alter_log_max_size = 268435456
max_prepared_stmt_count = 1048576
sort_buffer_size = '67108864'
sync_binlog = 1

W&B has validated these settings for performance and reliability.

Database creation

If you aren’t using a managed MySQL service that provisions the database automatically, follow these instructions to manually create the MySQL database and user that W&B Server uses:

Create a database and a user with the following SQL commands. Replace SOME_PASSWORD with a secure password of your choice:

CREATE USER 'wandb_local'@'%' IDENTIFIED BY 'SOME_PASSWORD';
CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION;

For additional considerations, including backups, performance, monitoring, and availability, see the reference architecture MySQL section.

Redis

W&B Server uses Redis for caching and background job coordination.

W&B depends on a single-node Redis 7.x deployment used by W&B’s components for job queuing and data caching. For convenience during testing and development of proofs of concept, W&B Self-Managed includes a local Redis deployment that is not appropriate for production deployments.

For production deployments, W&B can connect to a Redis instance in the following environments:

• AWS Elasticache
• Google Cloud Memory Store
• Azure Cache for Redis
• Redis deployment hosted in your cloud or on-premise infrastructure

W&B can connect to a Redis instance in any of the following environments:

• AWS Elasticache.
• Google Cloud Memory Store.
• Azure Cache for Redis.
• Redis deployment hosted in your cloud or on-premises infrastructure.

Object storage

W&B Server requires an object storage bucket to store artifacts, media, and run data.

W&B requires object storage with pre-signed URL and CORS support.

Recommended storage providers:

• Amazon S3: Object storage service offering industry-leading scalability, data availability, security, and performance.
• Google Cloud Storage: Managed service for storing unstructured data at scale.
• Azure Blob Storage: Cloud-based object storage solution for storing massive amounts of unstructured data.
• CoreWeave AI Object Storage: High-performance, S3-compatible object storage service optimized for AI workloads.
• Enterprise S3-compatible storage: MinIO Enterprise (AIStor), NetApp StorageGRID, or other enterprise-grade solutions

MinIO Open Source is in maintenance mode with no active development or pre-compiled binaries. For production deployments, W&B recommends using managed object storage services or enterprise S3-compatible solutions such as MinIO Enterprise (AIStor).

For detailed bucket provisioning instructions including IAM policies, CORS configuration, and access setup, see the Bring Your Own Bucket (BYOB) guide.

See the reference architecture object storage section for complete requirements.

Provision your storage bucket

Before configuring W&B, provision your object storage bucket with proper IAM policies, CORS configuration, and access credentials.

See the Bring Your Own Bucket (BYOB) guide for detailed step-by-step provisioning instructions for:

• Amazon S3 (including IAM policies and bucket policies)
• Google Cloud Storage (including PubSub notifications)
• Azure Blob Storage (including managed identities)
• CoreWeave AI Object Storage
• S3-compatible storage (MinIO Enterprise, NetApp StorageGRID, and other enterprise solutions)

Configure W&B to use your bucket

After you provision your bucket, you must configure W&B to use it through the Operator’s Helm values so that W&B Server can read from and write to the bucket. See the Operator object storage configuration section for details.

Networking

Networking configuration exposes W&B Server to users and machine-learning workloads. The following sections describe DNS, load balancer, and ingress requirements.

For a networked deployment, egress to these endpoints is required during both installation and runtime:

• https://deploy.wandb.ai
• https://charts.wandb.ai
• https://quay.io (used for Prometheus images)

Additional container registries may be required depending on your deployment configuration:

• https://gcr.io is needed when deploying Bufstream and etcd for Weave online evaluations.

To learn about air-gapped deployments, refer to Kubernetes operator for air-gapped instances.

Access to W&B and to the object storage is required for the training infrastructure and for each system that tracks the needs of experiments.

DNS

The fully qualified domain name (FQDN) of the W&B deployment must resolve to the IP address of the ingress or load balancer using an A record.

Load balancer and ingress

The W&B Kubernetes Operator exposes services using a Kubernetes ingress controller, which routes to service endpoints based on URL paths. The ingress controller must be accessible by all machines that execute machine-learning payloads or access the service through web browsers.

For detailed load balancer options, ingress controller requirements, and configuration examples, see the reference architecture load balancer section.

SSL/TLS

W&B requires a valid signed SSL/TLS certificate for secure communication between clients and the server. SSL/TLS termination must occur on the ingress/load balancer. The W&B Server application does not terminate SSL or TLS connections.

Important: W&B does not support self-signed certificates and custom CAs. Using self-signed certificates will cause challenges for users and is not supported.

If possible, using a service like Let’s Encrypt is a great way to provide trusted certificates to your load balancer. Services like Caddy and Cloudflare manage SSL for you.

If your security policies require SSL communication within your trusted networks, consider using a tool like Istio and side car containers.

License

All Self-Managed deployments require a valid W&B Server license. Without a license, W&B Server can’t start.

You need a W&B license to deploy W&B Self-Managed.

1. If you do not already have a W&B account, create one.
2. If you need an enterprise trial license with support for important security and other enterprise-friendly capabilities, submit a request or reach out to your W&B team.
3. Otherwise, open the Deploy Manager to generate a free trial license. The URL redirects you to a Get a License for W&B Local form. Provide the following information:
   • The owner of the license
   • The deployment type
   • A name and optional description for the instance
4. Click Generate License Key.

A page displays with an overview of your deployment along with the license associated with the instance.

Next steps

After you confirm that your infrastructure meets these requirements, proceed to the deployment guide that matches your environment:

• Cloud and on-premises deployments: See Deploy W&B with Kubernetes Operator for Helm and Terraform deployment options.
• Air-gapped deployments: See Deploy on Air-Gapped Kubernetes for disconnected environments.
• All deployment methods: See Deploy with Kubernetes Operator for the core operator deployment guide.