Skip to main content
This page provides a comprehensive overview of the infrastructure and software requirements for deploying W&B Self-Managed. Review these requirements before beginning your deployment.
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 simple and secure to use, with minimum to no configuration required.
For complete architectural guidance, see the reference architecture.

​
Software version requirements

SoftwareMinimum version
Kubernetesv1.32 or newer (Supported Kubernetes versions)
Helmv3.x
MySQLv8.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
Redisv7.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 these requirements:
  • Version: See Software version requirements above
  • 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: 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 strongly 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, patching, and significantly reduce operational complexity.

​
MySQL configuration parameters

If you are running your own MySQL instance, configure MySQL with these settings: 
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
These settings have been validated by W&B for optimal performance and reliability.

​
Database creation

For instructions to manually create the MySQL database and user: 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 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: W&B can connect to a Redis instance in the following environments:

​
Object storage

W&B requires object storage with pre-signed URL and CORS support. Recommended storage providers:
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 provisioning your bucket, you will configure W&B to use it through the Operator’s Helm values. See the Operator object storage configuration section for details.

​
Networking

For a networked deployment, egress to these endpoints is required during both installation and runtime:
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/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

A valid W&B Server license is required for all Self-Managed deployments. See Obtain your W&B Server license for instructions.

​
Next steps

After ensuring your infrastructure meets these requirements: