# JFrog Reference Architecture > Generated for LLM consumption # Search URL: https://jfrog.com/reference-architecture/search/ --- # Active Passive URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/active-passive/ > Active-passive multi-site deployment architecture for JFrog Platform SaaS. Covers failover configurations across cloud regions and providers, access and repository federation, and disaster recovery readiness with a passive backup site. Active/Passive with failover A main (Active) JFrog Platform site used by an organization with a passive JFrog Platform site (in a different cloud region or cloud provider) ready for failover Using Access and repository federation to keep data and Access entities in sync This architecture can be used for DR (Disaster Recovery) where the passive site acts as the backup platform See more details in the Disaster Recovery section The sites can be in different cloud providers as the federation is an application feature See Limitations Architecture The following is a schematic high level architecture of such a deployment. --- # Active Passive URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/active-passive/ > Active-passive multi-site deployment architecture for the self-managed JFrog Platform. Covers failover configurations, DNS routing, access and repository federation, and disaster recovery readiness with a passive backup site. Active/Passive with failover A main, active JFrog Platform deployment (jfrog-a.my.org) used by an organization with a passive JFrog Platform deployment (usually in a different data center) ready for failover (jfrog-b.my.org) A global DNS CNAME is defined (jfrog.my.org) with routing to (jfrog-a.my.org). In case of a failover is needed, the main DNS will be updated to point to the failover site (jfrog-b.my.org) All of the organization is using a single URL to access the JFrog Platform (jfrog.my.org) Using Access and repository federation to keep data and Access entities in sync This a common architecture used for DR (Disaster Recovery) readiness where the passive site acts as the backup platform See more details in the Disaster Recovery section See Limitations Architecture The following is a schematic high level architecture of such a deployment. --- # AWS Sizing URL: https://jfrog.com/reference-architecture/self-managed/deployment/sizing/aws/ > AWS infrastructure sizing recommendations for self-managed JFrog Platform deployments. Includes instance types for Artifactory, Nginx, Xray, JAS, and RDS PostgreSQL across different sizing templates using AWS Graviton instances. Last updated: June 2026 AWS Sizing When deploying a self-managed deployment of the JFrog Platform on AWS, it is important to consider the hardware and sizing requirements to ensure optimal performance and scalability. The following guidelines are recommended for sizing your AWS infrastructure. Artifactory NOTES: Each Artifactory replica should run in its own instance (prefer a dedicated node pool) The Nginx here refers to the instance bundled with Artifactory Each Nginx replica should run in its own instance (prefer a dedicated node pool) If using an ingress controller, you can omit the bundled Nginx, but should determine the appropriate number of ingress controller replicas for your deployment If using an ingress controller Set artifactory.ingress.enabled (or artifactory.artifactory.ingress.enabled when using the jfrog-platform chart) to true Set artifactory.nginx.enabled (or artifactory.artifactory.nginx.enabled when using the jfrog-platform chart) to false JFrog Distribution can run on the same nodes as Artifactory If you are enabling Platform Federation and/or AppTrust, use the Artifactory node pool rows marked (Federation / AppTrust). The higher vCPU counts provide headroom for the additional JFrog services. Size Template Small Medium Large XLarge 2XLarge Number of Artifactory Replicas 1 2 3 4 6 Number of Nginx Replicas 1 2 2 2 3 Artifactory node pool instance m8g.2xlarge m8g.2xlarge m8g.4xlarge m8g.4xlarge m8g.4xlarge vCPU 8 8 16 16 16 Memory 32 32 64 64 64 Artifactory node pool instance (Federation / AppTrust) c8g.4xlarge c8g.4xlarge c8g.8xlarge c8g.8xlarge c8g.8xlarge vCPU 16 16 32 32 32 Memory 32 32 64 64 64 Nginx node pool instance c8g.xlarge c8g.xlarge c8g.xlarge c8g.2xlarge c8g.2xlarge vCPU 4 4 4 8 8 Memory 8 8 8 16 16 PostgreSQL RDS instance db.m8g.2xlarge db.m8g.4xlarge db.m8g.8xlarge db.m8g.12xlarge db.m8g.16xlarge vCPU 8 16 32 48 64 Memory 32 64 128 192 256 Max connections 100 200 600 2000 5000 Xray NOTES: Each Xray replica should run in its own instance (prefer a dedicated node pool) Xray has HPA enabled, so more instances should be available if needed If running JAS, it’s recommended to use a dedicated node pool for it to protect Xray and Artifactory pods Size Template Small Medium Large XLarge 2XLarge Number of Xray Replicas 1 2 2 2 3 Number of RabbitMQ Replicas 1 3 3 3 3 Xray node pool instance c8g.2xlarge m8g.2xlarge m8g.2xlarge m8g.2xlarge m8g.2xlarge vCPU 8 8 8 8 8 Memory 16 32 32 32 32 RabbitMQ node pool instance c8g.xlarge c8g.xlarge c8g.xlarge c8g.xlarge c8g.xlarge vCPU 4 4 4 4 4 Memory 8 8 8 8 8 JAS node pool instance m8g.2xlarge m8g.2xlarge m8g.2xlarge m8g.2xlarge m8g.2xlarge vCPU 8 8 8 8 8 Memory 32 32 32 32 32 PostgreSQL RDS instance db.m8g.xlarge db.m8g.2xlarge db.m8g.4xlarge db.m8g.8xlarge db.m8g.12xlarge vCPU 4 8 16 32 48 Memory 16 32 64 128 192 Max connections 200 500 600 1200 2000 Storage See Storage Specifications for details on storage requirements and recommendations. --- # Deployment Considerations URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/ > Key deployment considerations for self-hosted JFrog Platform including runtime platform, hardware sizing, network configuration, high availability, database selection, storage planning, security, and migration strategies. Overview This section covers the deployment considerations for a self-hosted JFrog Platform. Deployment Considerations The considerations covered in this section are Runtime platform → Hardware and sizing → Network → High availability → Database → Storage → Security → Migration → --- # Disaster Recovery Playbook URL: https://jfrog.com/reference-architecture/disaster-recovery/dr-playbook/ > Guide to creating and maintaining a disaster recovery playbook for the JFrog Platform. Covers roles and responsibilities, step-by-step recovery procedures, communication plans, testing processes, and RTO/RPO definitions for different scenarios. Overview A Disaster Recovery (DR) playbook is a documented set of procedures and guidelines designed to help organizations respond quickly and effectively to disruptive incidents. It outlines the specific steps, roles, and resources required to restore critical systems and services, minimize downtime, and reduce data loss. The playbook serves as a practical guide for IT and operations teams, ensuring that everyone knows what to do before, during, and after a disaster to maintain business continuity. The Playbook The DR playbook should define: Roles and responsibilities during a disaster event For example: Assigning an Incident Commander to coordinate the response Designating team members responsible for system restoration, communications, and documentation Identifying backup personnel in case primary responders are unavailable Define the global coverage of an incident to be able to operate around the clock Step-by-step recovery procedures for each scenario For example: Detailed instructions for restoring from the latest backup after a ransomware attack Procedures for failing over to a secondary site in the event of a data center outage Steps to isolate and remediate compromised systems during a security breach Communication plans for stakeholders For example: Predefined notification templates for informing executives, IT staff, and end users Escalation paths for critical incidents Regular status updates to stakeholders throughout the recovery process Testing and validation processes to ensure recovery success For example: Scheduling regular DR drills and tabletop exercises Checklists for verifying that restored systems are fully operational Post-recovery reviews to identify gaps and improve future responses RTOs and RPOs for each use case For example: Defining a 4-hour Recovery Time Objective (RTO) for restoring critical services Setting a 1-hour Recovery Point Objective (RPO) for transactional databases Documenting different RTOs/RPOs for various applications based on business impact --- # JFrog Architecture URL: https://jfrog.com/reference-architecture/architecture/ > Overview of the JFrog Platform architecture, including core components for DevOps, DevSecOps, DevGovOps, and MLOps. Learn about Artifactory, Xray, Distribution, and other platform services that form a comprehensive software supply chain management solution. Overview The JFrog Platform is an end-to-end DevOps/DevSecOps/DevGovOps/MLOps platform that powers software supply chain management. It provides a unified experience for managing your entire software release flow, from development to distribution to production. Core Components The JFrog Platform provides solutions in the following areas DevOps Package management, CI/CD, and release management JFrog Artifactory - Universal artifact repository manager JFrog Distribution - Software distribution and release bundle management JFrog Connect - IoT and edge device management DevSecOps End-to-end security natively where your code and artifacts live. JFrog Xray - Code and binary level software composition analysis JFrog Curation - Defend your software supply chain with a “package firewall” for third party OSS packages JFrog Advanced Security - Advanced application security testing with contextual analysis JFrog Catalog - Centralized OSS and CVE catalog with security and risk insights JFrog Runtime - Runtime security and compliance for Kubernetes production environments Source Code - Shift-left security and compliance for source code DevGovOps Control governance, risk, and compliance as part of your DevOps lifecycle JFrog AppTrust - Ensuring trusted, secure, and compliant application releases AI/ML All-in-one solution to build, deploy, manage and monitor all your AI workflows, from GenAI and LLMs to classic ML JFrog ML - Tools, integrations, environments, and out-of-the box approach needed for successful AI/ML development JFrog AI Catalog - Central hub for discovering, governing, and accessing AI models Platform Architecture The diagram below illustrates how these components work together to form a comprehensive DevOps platform: Key Architectural Benefits Unified Management - Single pane of glass for all DevOps, DevSecOps, Machine Learning and AI operations Scalable Design - Microservices-based architecture with high availability Enterprise Ready - Support for multi-site architecture and disaster recovery requirements Security First - Built-in security controls and vulnerability scanning API Driven - RESTful APIs for automation and integration Learn More Go to the JFrog Platform’s official website to learn more about the single source of truth for your software supply chain. --- # JFrog SaaS URL: https://jfrog.com/reference-architecture/jfrog-saas/ > JFrog SaaS is the recommended cloud-native, fully managed JFrog Platform service. Learn about enterprise-grade reliability, scalability, security, and global availability across AWS, Azure, and Google Cloud with 99.9% uptime SLA. Overview JFrog SaaS is the recommend way to consume the JFrog Platform. JFrog SaaS provides the cloud-native JFrog Platform as a fully managed service in your cloud provider and region of choice with enterprise-grade reliability, scalability, and security. For a complete list of supported cloud providers and available regions, visit the JFrog Help Center. In rapidly evolving technology landscapes such as AI/ML, JFrog SaaS ensures your organization’s developers and data scientists always have access to the latest package manager and protocol support—keeping you ahead of the curve. See common use cases for getting the best out of JFrog SaaS. Enterprise-Grade Platform High Availability: 99.9% or 99.99% Premium uptime SLA Global Presence: Multiple regions across AWS, Azure, and Google Cloud. See details Massive Scale: Support for petabyte-scale storage and hundreds of thousands of requests per minute Zero Maintenance: Fully managed service with automatic updates and latest security patches Key Benefits Instant Setup: Get started in minutes with pre-configured environments Auto-Scaling: Dynamically scaled resources based on your needs Global Distribution: Access your artifacts from anywhere with optimal latency Enterprise Security: Built-in security features including SSO, encryption at rest and in transit Cost Optimization: Pay only for what you use with no infrastructure overhead Service Level Agreement (SLA) JFrog SaaS provides enterprise-grade SLAs ensuring: 99.9% standard and 99.99% premium availability 24/7 monitoring and support Automated backup and disaster recovery Regular security updates and compliance maintenance Reference: JFrog Trust --- # One Way Network Access URL: https://jfrog.com/reference-architecture/self-managed/use-cases/air-gapped/one-way-network/ > One-way network access architecture for air-gapped JFrog Platform deployments. Covers controlled unidirectional connectivity, smart remote repositories, pull replication, and operational advantages for secure artifact acquisition. Overview One-way network access in an air-gapped environment represents a controlled unidirectional communication channel that allows internal systems to initiate connections to external networks while strictly preventing any inbound connections. This approach provides a balance between security isolation and operational efficiency. If your constraints are closer to hybrid deployments—SaaS and self-managed JFrog Platform Deployments where inbound access to on-premises is blocked but outbound tunnels are acceptable—the Hybrid with JFrog Bridge scenario describes how JFrog Bridge carries federation and related traffic over client-initiated connections. Architecture This is a typical Artifactory deployment in a one-way network air-gapped environment. Note that the JFrog Platform on both sides includes JFrog’s Security solutions like JFrog Xray. One-Way Connection Scenario Controlled Unidirectional Access This scenario allows limited, controlled connectivity from the internal environment to external systems, enabling more automated artifact acquisition while maintaining security boundaries. Architecture Characteristics Internal Artifactory instance can initiate connections to external systems External systems cannot initiate connections to internal environments Connections are typically proxied through secure gateways with traffic filtering Network traffic is monitored, logged, and subject to security policies Operational Models Smart Remote Repositories Internal Artifactory uses remote repositories that proxy external Artifactory instances External instances serve as trusted intermediaries for public repositories Artifact requests flow through secure, unidirectional connections Caching occurs at both external and internal levels for performance optimization Pull Replication Internal repositories configured to pull approved artifacts from external instances Scheduled replication jobs transfer pre-approved dependencies Automated synchronization of whitelisted artifact collections Centralized control over which artifacts are made available internally Security Benefits Controlled access to external resources with security oversight Automated artifact acquisition reduces manual overhead Maintains network isolation while enabling necessary connectivity Comprehensive logging and monitoring of all external communications Operational Advantages Reduced delays in dependency acquisition compared to no-connection scenarios Automated processes reduce human error and operational overhead Better support for CI/CD automation and developer productivity Simplified artifact management and synchronization procedures --- # Runtime Platform URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/runtime-platform/ > Runtime platform recommendations for the JFrog Platform. Covers Kubernetes deployment using Helm charts, dedicated node pools for different services, pod anti-affinity configurations, and topology guidelines for production-grade deployments. Runtime Platform The recommended platform to install and run the JFrog Platform applications on is Kubernetes. The JFrog Platform should be deployed in Kubernetes using the jfrog-platform helm chart. Why Kubernetes? Compared with older install methods (archive, RPM/DEB, Docker Compose, or per-host VM setups), Kubernetes is the better option because: Unified, cluster-wide deployment: One jfrog-platform Helm chart installs and manages all components across the cluster—unlike host-by-host installs or single-host Docker Compose stacks. Easy multi-node scaling: Scale pods or resources per service across nodes on demand, without provisioning VMs or being limited to one Compose host. Safer upgrades: Helm rolling upgrades replace stop-and-start package or Compose recreates, with less downtime and less version drift. Built-in HA: Pod restarts (AKA auto healing), replicas, and node failover replace custom clustering scripts, manual VM failover, or single-host Compose setups. Consistent operations: The same charts and practices work on-prem, cloud, or hybrid—avoiding environment-specific install playbooks. Kubernetes Topology guidelines For a production grade, high performance and resilience JFrog Platform deployment, see the following guidelines: A dedicated node pool should be allocated for each of the following JFrog applications to best fit their necessary resources and for workload isolation Artifactory Ingress (Nginx or equivalent) Xray Advance Security (JAS) PodAntiAffinity Require Artifactory pods anti-affinity between them Prefer Xray pods anti-affinity between each other Require Xray pods anti-affinity between them and Artifactory pods Require JAS pods anti-affinity between them and Artifactory and Xray pods Require Ingress controller/Nginx pods anti-affinity between them and also Xray and Artifactory pods Best is to use a dedicated node group for Ingress controller pods Prefer Xray RabbitMQ pods anti-affinity between them, Artifactory and Xray pods If running the databases (PostgreSQL) in Kubernetes, it must require pods anti-affinity with all JFrog applications and ingress/nginx pods Terraform Example See an example in the JFrog Charts repository, for a Terraform configuration that creates the necessary AWS infrastructure and services required to run the JFrog Platform and follow the guidelines above. --- # Single Site URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/single-site/ > Single site deployment architecture for JFrog Platform SaaS in a single cloud region. Covers benefits, limitations, and when this deployment pattern is appropriate. Supports AWS, GCP, and Azure cloud providers. Single Site A single JFrog Platform SaaS site in a given cloud region. The supported Cloud providers are AWS, GCP and Azure. The JFrog Platform serves one or more organizations. Benefits of a Single Site Streamlines deployment and management by operating a single site A faster setup and accelerated onboarding No dependency on other sites A single source of truth (no conflicts) Important: Being a single site, there is a very limited failover capability. It is highly recommended to look into the multi site as the architecture of choice for stronger durability and availability. Architecture The following is a schematic high level architecture of such a site. --- # Single Site URL: https://jfrog.com/reference-architecture/self-managed/use-cases/single-site/ > Single site deployment architecture for the JFrog Platform in a single data center, ideally on Kubernetes. Learn about benefits, limitations, and when this deployment pattern is appropriate for organizations. Single Site A single deployment of the JFrog Platform in a data center. Ideally in Kubernetes. The JFrog Platform serves one or more organizations. Benefits of a Single Site Deployment Streamlines deployment and management by operating a single site A faster setup and accelerated onboarding No dependency on other deployments A single source of truth (no conflicts) Important: Being a single site deployment, there is a very limited failover capability. It is highly recommended to look into the multi site deployment as the architecture of choice for stronger durability and availability. Architecture The following is a schematic high level architecture of such a deployment. --- # Use Cases URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/ > Common use cases for JFrog Platform SaaS deployments including single site, multi-site and archiving architectures across different cloud regions. Learn about deployment patterns optimized for cloud-native environments. Overview There are many use cases for the JFrog Platform SaaS. In this section, several of the common ones are described. Explore the Use Cases The main two use cases are: Single Site → A single site of the JFrog Platform SaaS in a given cloud region. The JFrog Platform site serves the whole organization Multi Site → Multiple sites of the JFrog Platform SaaS in different cloud regions (or even providers). A JFrog Platform site serves one or more organizations Smart Archiving → Manage artifact lifecycle and reduce costs with automated JFrog Smart Archiving. --- # Use Cases URL: https://jfrog.com/reference-architecture/self-managed/use-cases/ > Common use cases for self-managed JFrog Platform deployments including single site, multi-site, and air-gapped network scenarios. Learn about different architectural patterns and their benefits for various organizational requirements. Overview There are many use cases for the JFrog Platform. In this section, several of the common ones are described. Explore the Use Cases The main two use cases are: Single Site → A single site of the JFrog Platform in a given data center. The JFrog Platform site serves the whole organization. Multi Site → Multiple sites of the JFrog Platform in different data centers. A JFrog Platform site serves one or more organizations. Air Gapped Networks → A network physically isolated from unsecured networks to prevent unauthorized access. Smart Archiving → Manage artifact lifecycle and reduce costs with automated JFrog Smart Archiving in self-managed deployments. --- # Active Active URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/active-active/ > Active-active multi-site deployment architecture for JFrog Platform SaaS. Covers global DNS with geolocation load balancing, access and repository federation across cloud providers, and disaster recovery capabilities. Active/Active with global DNS Two active JFrog Platform sites used by one or more organizations with a single DNS The DNS uses a geolocation or latency-based load balancing Using Access and repository federation to keep data and Access entities in sync The sites can be in different cloud providers as the federation is an application feature This architecture can be used for DR (Disaster Recovery) where the sites act as each other’s failover See more details in the Disaster Recovery section See Limitations Architecture The following is a schematic high level architecture of such a topology. --- # Active Active URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/active-active/ > Active-active multi-site deployment architecture for the self-managed JFrog Platform. Covers global DNS routing, access and repository federation, disaster recovery capabilities, and high availability configurations. Active/Active with global DNS Two active JFrog Platform deployments (jfrog-a.my.org and jfrog-b.my.org) A global DNS CNAME is defined (jfrog.my.org) with routing to both sites with a pre-defined routing policy. See example of AWS Route53 routing policies Using Access and repository federation to keep data and Access entities in sync This architecture can be used for DR (Disaster Recovery) where the sites act as each other’s failover See more details in the Disaster Recovery section See Limitations Architecture The following is a schematic high level architecture of such a topology. --- # AWS URL: https://jfrog.com/reference-architecture/self-managed/deployment/aws/ > Deployment recommendations for the JFrog Platform on Amazon Web Services (AWS). Covers EKS for compute, S3 for storage, RDS PostgreSQL for database, and best practices for high availability using AWS Graviton instances. Overview When deploying on AWS, consider the following recommendations. Diagram Compute Use AWS Elastic Kubernetes Service (EKS) for running the JFrog Platform applications. As Artifactory supports ARM, it’s recommended to use the AWS Graviton instance types for better performance and lower costs. Storage Server Local Storage High-performance local storage is essential for Artifactory’s cache-fs, as it significantly affects overall Artifactory performance. See the recommended storage specifications in the Sizing section. Filestore Use an AWS Simple Storage Service (S3) bucket to store the Artifactory binaries Database Use AWS Relational Database Service (RDS) for PostgreSQL as the application’ database. Use an RDS multi zone deployment with one or two standby replicas. This allows for higher durability in case of a zone or instance failure. Use the AWS Graviton based instance types for better performance at a lower cost. See recommended storage specifications in the Sizing section. --- # Azure Sizing URL: https://jfrog.com/reference-architecture/self-managed/deployment/sizing/azure/ > Azure infrastructure sizing recommendations for self-managed JFrog Platform deployments. Includes Azure VM instance types for Artifactory, Nginx, Xray, JAS, and Azure Flexible Server PostgreSQL configurations across different sizing templates. Last updated: June 2026 Azure Sizing When deploying a self-managed deployment of the JFrog Platform on Azure, it is important to consider the hardware and sizing requirements to ensure optimal performance and scalability. The following guidelines are recommended for sizing your Azure infrastructure. Artifactory NOTES: Each Artifactory replica should run in its own instance (prefer a dedicated node pool) The Nginx here refers to the instance bundled with Artifactory Each Nginx replica should run in its own instance (prefer a dedicated node pool) If using an ingress controller, you can omit the bundled Nginx, but should determine the appropriate number of ingress controller replicas for your deployment If using an ingress controller Set artifactory.ingress.enabled (or artifactory.artifactory.ingress.enabled when using the jfrog-platform chart) to true Set artifactory.nginx.enabled (or artifactory.artifactory.nginx.enabled when using the jfrog-platform chart) to false JFrog Distribution can run on the same nodes as Artifactory If you are enabling Platform Federation and/or AppTrust, use the Artifactory node pool rows marked (Federation / AppTrust). The higher vCPU counts provide headroom for the additional JFrog services. Size Template Small Medium Large XLarge 2XLarge Number of Artifactory Replicas 1 2 3 4 6 Number of Nginx Replicas 1 2 2 2 3 Artifactory node pool instance Standard_D8s_v6 Standard_D8s_v6 Standard_D16s_v6 Standard_D16s_v6 Standard_D16s_v6 vCPU 8 8 16 16 16 Memory 32 32 64 64 64 Artifactory node pool instance (Federation / AppTrust) Standard_F16s_v2 Standard_F16s_v2 Standard_F32s_v2 Standard_F32s_v2 Standard_F32s_v2 vCPU 16 16 32 32 32 Memory 32 32 64 64 64 Nginx node pool instance Standard_F4s_v2 Standard_F4s_v2 Standard_F4s_v2 Standard_F8s_v2 Standard_F8s_v2 vCPU 4 4 4 8 8 Memory 8 8 8 16 16 Azure Flexible Server instance E8ds_v6 E16ds_v6 E20ds_v6 E32ds_v6 E48ds_v6 vCPU 8 16 20 32 48 Memory 64 128 160 256 384 Max connections 100 200 600 2000 5000 Xray NOTES: Each Xray replica should run in its own instance (prefer a dedicated node pool) Xray has HPA enabled, so more instances should be available if needed If running JAS, it’s recommended to use a dedicated node pool for it to protect Xray and Artifactory pods Size Template Small Medium Large XLarge 2XLarge Number of Xray Replicas 1 2 2 2 3 Number of RabbitMQ Replicas 1 3 3 3 3 Xray node pool instance Standard_F8s_v2 Standard_D8s_v6 Standard_D8s_v6 Standard_D8s_v6 Standard_D8s_v6 vCPU 8 8 8 8 8 Memory 16 32 32 32 32 RabbitMQ node pool instance Standard_F4s_v2 Standard_F4s_v2 Standard_F4s_v2 Standard_F4s_v2 Standard_F4s_v2 vCPU 4 4 4 4 4 Memory 8 8 8 8 8 JAS node pool instance Standard_D8s_v6 Standard_D8s_v6 Standard_D8s_v6 Standard_D8s_v6 Standard_D8s_v6 vCPU 8 8 8 8 8 Memory 32 32 32 32 32 Azure Flexible Server instance E4ds_v6 E8ds_v6 E16ds_v6 E20ds_v6 E32ds_v6 vCPU 4 8 16 20 32 Memory 16 32 64 160 256 Max connections 200 500 600 1200 2000 Storage See Storage Specifications for details on storage requirements and recommendations. --- # Deployment URL: https://jfrog.com/reference-architecture/self-managed/deployment/ > Deployment options and best practices for the self-managed JFrog Platform. Covers Kubernetes deployment using Helm charts, cloud provider deployments (AWS, Azure, GCP), private datacenter installations, and common requirements for high availability, storage, and security. Overview The JFrog Platform can be deployed in various environments, with Kubernetes being the recommended deployment method. Our official JFrog Platform Helm chart provides a production-grade, easy-to-maintain deployment solution. Kubernetes Deployment The JFrog Platform Helm chart offers: Unified deployment of all platform components Built-in high availability configuration Automated upgrades Integration with cloud-native storage and databases Predefined sizing templates for different scale requirements Deployment Considerations Before you deploy the JFrog Platform, it is important to be aware of several critical considerations, including platform compatibility, sizing, networking, storage, security, and migration strategies. Deployment Considerations → Deployment Options The JFrog Platform can be deployed in several environments, including: Amazon Web Services (AWS) → Amazon Elastic Kubernetes Service (EKS) Integration with AWS services (S3, RDS, etc.) Regional and multi-region deployments Microsoft Azure → Azure Kubernetes Service (AKS) Integration with Azure services (Blob Storage, Database, etc.) Support for Azure Government Cloud Google Cloud Platform (GCP) → Google Kubernetes Engine (GKE) Integration with GCP services (Cloud Storage, Cloud SQL, etc.) Support for private GKE clusters Private Data Center → On-premises Kubernetes clusters on virtual machines (VMware, Hyper-V, KVM, etc.) Optional bare-metal Kubernetes where your organization requires it Common Requirements Regardless of the deployment environment, consider these key aspects: High availability configuration External database (PostgreSQL) Scalable object storage Network security and access control Monitoring and logging setup Disaster recovery and backup strategies Each deployment option is detailed in the sections on the left navigation menu with specific configurations and best practices. --- # Disaster Recovery Tiers URL: https://jfrog.com/reference-architecture/disaster-recovery/dr-tiers/ > Overview of the seven standardized disaster recovery tiers (Tier 0-7) that categorize different levels of data protection and recovery capabilities. Learn about RTO, RPO, and how to select the appropriate DR tier for your organization. Overview The disaster recovery industry recognizes seven standardized tiers (Tier 0-7) that categorize different levels of data protection, recovery capabilities, and infrastructure requirements. Understanding these tiers helps organizations select the appropriate DR strategy based on their Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and budget constraints. Each tier represents an increasing level of sophistication, cost, and recovery capability, from basic on-site backups to fully automated disaster prevention systems. The 7 Tiers of Disaster Recovery Tier 0: No Off-Site Data Description: All data stored on-site with no off-site backup Storage: Magnetic tape or disk drives on premises RTO: Indefinite (potentially weeks or never) RPO: High data loss risk Use Case: Very low-budget scenarios with non-critical data Risk: Highest risk - natural disasters can cause complete data loss Tier 1: Physical Backup With Cold Site Description: Off-site facility with no IT equipment pre-installed Storage: Physical backup transported to cold site RTO: 1+ weeks (time to procure and install hardware) RPO: Time since last physical backup Use Case: Organizations with longer acceptable downtime Limitations: Requires hardware procurement and setup after disaster Tier 2: Physical Backup With Hot Site Description: Off-site facility pre-equipped with necessary IT hardware Storage: Physical backup with pre-installed infrastructure RTO: Days RPO: Time since last physical backup Use Case: Mission-critical systems with moderate RTO requirements Advantage: Pre-configured hardware reduces recovery time Tier 3: Electronic Vaulting Description: Electronic transfer of backup data to off-site location Storage: Hard drives, tape drives, optical storage RTO: Less than 24 hours RPO: More frequent backups possible due to electronic transfer Use Case: Organizations requiring daily backup frequency Advantage: Eliminates physical transportation delays Tier 4: Point-in-Time Recovery Description: Active secondary site with scheduled data synchronization Storage: Disk, SSD, and cloud storage RTO: Less than 24 hours RPO: Last synchronization point (typically end of business day) Use Case: Organizations requiring recent restore points Features: Two sites backing up each other Tier 5: Two-Site Commit/Transaction Integrity Description: Continuous data transmission to alternate sites Storage: Cloud-based continuous backup RTO: Less than 1 hour RPO: Minutes (continuous backup) Use Case: Financial services, healthcare, critical operations Requirement: Robust cloud infrastructure and bandwidth Tier 6: Minimal to Zero Data Loss Description: Real-time data replication with disk mirroring Storage: Synchronized disk mirroring and data replication RTO: Minutes RPO: Near-zero (real-time replication) Use Case: Banking, trading systems, life-critical applications Features: Immediate failover capability Tier 7: Highly Automated Disaster Recovery Description: Proactive monitoring and automated disaster prevention Storage: AI-driven predictive backup systems RTO: Preventive (aims to avoid disasters) RPO: Continuous protection Use Case: Mission-critical systems requiring maximum uptime Features: AI monitoring, automated threat detection, predictive backup Selecting the Right Tier Factors to Consider Business Impact Analysis: Critical system downtime costs Acceptable data loss limits Regulatory compliance requirements Customer service level agreements Technical Requirements: Current infrastructure capabilities Network bandwidth availability Storage capacity needs Geographic distribution requirements Budget Constraints: Initial implementation costs Ongoing operational expenses Cost of downtime vs. DR investment Resource allocation priorities Tier Mapping to Common Requirements Business Type Typical Tier RTO Target RPO Target Small Business (non-critical) Tier 1-2 1-7 days 24 hours Standard Enterprise Tier 3-4 4-24 hours 1-4 hours Financial Services Tier 5-6 < 1 hour < 15 minutes Critical Infrastructure Tier 6-7 < 15 minutes Near-zero Implementation Considerations Progressive Approach Organizations often start with lower tiers and gradually advance as: Business criticality increases Budget allows for infrastructure investment Technical expertise develops Compliance requirements evolve Hybrid Strategies Different systems within an organization may warrant different tiers: Tier 6-7: Core transaction systems Tier 4-5: Important business applications Tier 2-3: Supporting systems and archives Cost-Benefit Analysis Higher tiers provide better protection but require significant investment. Organizations must balance: Recovery capability improvements Infrastructure and operational costs Risk tolerance and business impact Regulatory and compliance requirements Reference For detailed information about disaster recovery tiers, see: Understanding the 7 Tiers of Disaster Recovery --- # Hardware and Sizing URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/hardware-and-sizing/ > Hardware and sizing considerations for self-managed JFrog Platform deployments. Provides guidance on resource planning and links to detailed sizing documentation for optimal performance and scalability. Hardware and Sizing When deploying a self-managed instance of the JFrog Platform, it is important to consider the hardware and sizing requirements to ensure optimal performance and scalability. NOTE: The JFrog Platform is fully supported on virtual machines; bare metal is not required. Sizing values represent compute cores—treat them as vCPUs on cloud and virtualized environments, or as CPU cores on bare metal. The numeric values are the same in both cases. Cloud instance types in the tables are examples; any instance or on-prem node meeting the vCPU/core and memory values is acceptable. Refer to Sizing page for guidelines and details. --- # JFrog Self Managed URL: https://jfrog.com/reference-architecture/self-managed/ > Guide to self-managed JFrog Platform deployments, including hybrid and on-premise installations. Covers use cases, deployment considerations, and best practices for organizations managing their own JFrog Platform infrastructure. Overview The JFrog Platform can be deployed in a variety of ways to meet the needs of different organizations. This section covers some of the other deployment options available, including: Hybrid: SaaS and Self Hosted with connections between them (like federation, distribution, smart remote repositories, etc.) On-Premise Self Hosted. A fully self-managed installation and configuration of the JFrog Platform. One or more sites Getting Started The two areas covered in this section are Use Cases Learn about the popular JFrog Platform deployment architecture use cases. Deployment Learn the considerations, recommendations and best practices for your JFrog Platform deployment. JFrog SaaS Unless not possible, it is highly recommended to choose the JFrog SaaS option. This is the most cost-effective and easiest way to get started with the JFrog Platform. The JFrog SaaS option is a fully managed service that provides all the features of the JFrog Platform without the need for any installation or configuration. --- # Multi Site URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/ > Multi-site deployment architecture for JFrog Platform SaaS across multiple cloud regions. Covers active-passive and active-active configurations, access and repository federation, DNS routing, disaster recovery, and performance optimization for distributed teams. Multi Site (Recommended) This is a true production grade setup. Especially for large, multi site organizations. In a multi site architecture, multiple instances of the JFrog Platform Service in different locations are connected offering higher durability and redundancy. Usually serving multiple organizations in different geographic locations that share some or all of the data between them using access and repository federation. Benefits of Multi Sites Consider the following benefits of using Multi Sites with JFrog SaaS Higher availability of critical company assets across multiple cloud regions The Active/Passive setup can help implement a company DR (Disaster Recovery) or BCP (Business Continuity Plan) strategy Better performance for the different teams using the closer site Considerations in using SaaS Multi Sites Additional considerations when using JFrog SaaS Multi Sites In disaster recovery scenarios, sites can be remote from each other, meaning they could be geographically separated in different regions. There will be an impact on federation times due to higher latency With JFrog SaaS, you can manage a single DNS name for multiple sites and self-manage the failover when needed. See DNS Routing in MyJFrog Limitations With the Multi-Site architecture, JFrog federation features have some limitations to be aware of When federation is enabled, it is very much impacted by network latency, so need to allow time for a package in a local federated repository to be visible in the remote site’s repository Only Access and Repository federation are supported. Objects outside of these two are not federated, and should be managed individually per each JFrog Platform deployment JFrog Xray and Distribution do not have any federation capabilities yet, so each site will have to be configured separately to use these applications --- # Multi Site URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/ > Multi-site deployment architecture for the JFrog Platform across multiple geographic locations. Learn about active-passive and active-active configurations, federation, replication, and best practices for production-grade deployments. Multi Site (Recommended) This is a true production grade setup. Especially for large, multi site organizations. In a multi site architecture, multiple instances of the JFrog Platform Service in different locations are connected offering higher durability and redundancy. Usually serving multiple organizations in different geographic locations that share some or all of the data between them using features like federation or replication. Benefits of a Multi Site deployment Higher availability of critical company assets across multiple geographical locations The Active/Passive setup, can be part of the company DR (Disaster Recovery) strategy Better performance for the different teams using the platform (closer to their relevant deployment) Considerations in using a Multi Site deployment In disaster recovery scenarios, sites can be remote from each other, meaning they could be geographically separated in different regions. There will be an impact on replication or federation times due to higher latency If using the same URL for accessing the sites, ensure a unique base URL is set to each site and a reverse proxy sends the X-JFrog-Override-Base-Url with the common URL value For example: The URL main.domain.com has two endpoints - site1.domain.com and site2.domain.com and routes to the nearest server Each of the two sites should have their base URL set (site1.domain.com and site2.domain.com) The reverse proxy sends the X-JFrog-Override-Base-Url with the value of main.domain.com The common base URL ensures all links returned to clients are with the main.domain.com URL The unique base URL per site is needed for the setup of the federation where each site has to have a unique URL for the federation setup Use latency based on geolocation DNS routing policies See more technical details in geo location load balancer setup See latency guidance under federated repository best practice --- # No Network Access URL: https://jfrog.com/reference-architecture/self-managed/use-cases/air-gapped/no-network/ > No network access architecture for completely isolated air-gapped JFrog Platform deployments. Covers physical media transfer, manual artifact import/export processes, and maximum security isolation requirements. Overview No network access is a complete physical isolation between internal and external networks, with no direct network connectivity whatsoever. Data transfers can only occur through secure physical media like encrypted drives, requiring strict manual processes and security controls for any movement of artifacts or dependencies. Architecture This is a typical Artifactory deployment in a no-network air-gapped environment. Note that the JFrog Platform on both sides includes JFrog’s Security solutions like JFrog Xray. No Network Connection Scenario Complete Physical Isolation In this scenario, the internal and external environments have absolutely no network connectivity between them. This represents the highest level of security isolation but requires the most complex operational procedures. Architecture Characteristics Internal Artifactory instance operates completely disconnected from external networks External Artifactory instance on DMZ has internet access for dependency acquisition Physical media (removable drives, secure transfer devices) serves as the only data bridge All artifact transfers require manual intervention and physical transport Operational Model Dependencies are identified and requested through formal processes This should ideally be an automated process as much as possible to ease developers experience External instance downloads and validates all required artifacts and their transitive dependencies Approved artifacts are exported to secure, encrypted physical media Internal instance imports artifacts from physical media for internal distribution All transfers undergo security scanning and approval workflows Security Benefits Complete immunity from network-based attacks and data exfiltration Physical control over all data movement and artifact transfers Maximum protection for classified or highly sensitive development activities Absolute prevention of unauthorized external communications Operational Challenges Significant delays in dependency acquisition and updates Complex coordination required between internal and external teams Physical security requirements for data transfer media Manual processes prone to human error and delays --- # Air Gapped URL: https://jfrog.com/reference-architecture/self-managed/use-cases/air-gapped/ > Deployment strategies for the JFrog Platform in air-gapped networks with complete or partial isolation from unsecured networks. Covers one-way connection and no-network scenarios, security considerations, and operational procedures for high-security environments. Overview An air-gapped network is a security measure that ensures complete physical or logical isolation from unsecured networks, particularly the internet. This isolation prevents unauthorized access, data exfiltration, and cyber attacks by creating an impenetrable barrier between sensitive systems and external threats. Air-gapped environments are commonly deployed in organizations with the highest security requirements, including financial institutions, military installations, government agencies, and critical infrastructure providers where data security and operational integrity are paramount. Challenges for Software Development and CI/CD Dependency Management No direct access to public repositories (Maven Central, npm, PyPI, Docker Hub) All dependencies must be pre-positioned internally Manual dependency resolution and version management Build tools, frameworks and all their dependencies require internal hosting Developers are restricted to internal resources only Security and Compliance Rigorous security scanning and approval processes for external artifacts Formal change management for updates and patches Strict audit and compliance tracking requirements Operational Impact Reduced development velocity due to dependency access constraints Limited ability to experiment with new tools and libraries Complex environment synchronization across dev/stage/prod Restricted access to external support resources and documentation Common Implementation Considerations Key considerations when implementing the JFrog Platform in an air-gapped network. Deployment Multi-Instance Deployment Two Artifactory instances required: external for security/validation and internal for development The external Artifactory can be a JFrog SaaS site External instance acts as security boundary Internal instance provides artifacts and tools High availability planning needed for both environments Security Infrastructure Artifact scanning and validation pipelines Encrypted storage and transfer mechanisms Comprehensive audit logging and monitoring Incident response procedures Operational Procedures Artifact Management & Compliance Processes for requesting and approving external dependencies Version control and change management procedures Regular security updates and vulnerability remediation Documentation, approval workflows and compliance reporting Air-Gapped Deployment Scenarios Organizations implementing air-gapped environments typically employ one of two primary connectivity models, each with distinct operational characteristics and security implications. One-Way Connection Scenario → This scenario allows limited, controlled connectivity from the internal environment to external systems, enabling more automated artifact acquisition while maintaining security boundaries. No Network Connection Scenario → In this scenario, the internal and external environments have absolutely no network connectivity between them. This represents the highest level of security isolation but requires the most complex operational procedures. Air-gapped environments represent the pinnacle of network security but require careful planning, robust processes, and specialized tooling to maintain software development productivity and operational efficiency. References Using Artifactory in an Air Gapped Network Law enforcement achieves secured software development with JFrog --- # Archiving URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/archiving/ > JFrog Smart Archiving solution for managing artifact lifecycle in SaaS deployments. Covers automated archiving policies, compliance and security preservation, operational efficiency improvements, and cost optimization for inactive artifacts. Smart Archiving JFrog Smart Archiving is a solution designed to manage the lifecycle of development artifacts that are no longer in active use but must be retained for compliance, audit, or historical purposes. It provides organizations with the flexibility to define granular policies that determine which packages to archive and when. This process is fully automated and ensures that all essential metadata, security attestations, and compliance data are preserved and remain fully accessible for restores if and when needed. Why Smart Archiving? The Cost of “Digital Dust” As development repositories grow, they accumulate “Digital Dust”—a build-up of obsolete releases, end-of-life artifacts, and orphaned dependencies. This unmanaged data, a lot of which cannot be simply deleted, creates significant and escalating business friction. The “cost” of this dust is not just financial; it impacts the entire organization: Productivity Drain: Developers face slowdowns as CI/CD pipelines lag. Locating current, trusted artifacts becomes a “needle in a haystack” problem, wasting valuable engineering time. Performance Brake: Bloated repositories slow down release cycles, degrade overall system performance, and can increase failure rates in production. Security & Compliance Holes: Every unmanaged artifact expands the potential attack surface. This “dust” creates a significant, unmonitored risk of failed audits and security vulnerabilities. Financial Tax: The direct cost of storing and transferring this ever-growing, inactive data is a continuous and unnecessary financial drain. The Solution: Three Pillars of Trust Smart Archiving is designed to turn this “Digital Dust” into a managed, compliant, and trusted archive. The solution is built on three core pillars: Ensure Bulletproof Compliance & Security Full Traceability: Generates detailed reports (e.g., “what would be archived?” and “what was archived?”) to provide a clear audit trail. Dry Run Capability: Allows teams to test and validate policies without moving any data, ensuring policy accuracy before execution. Seamless Retrieval: All metadata and evidence are preserved and remain available, ensuring you can prove compliance instantly. Improve Operational Efficiency Optimized Repositories: By moving inactive data, active repositories remain lean, fast, and responsive. Performance Gains: Directly reduces CI/CD pipeline friction and improves overall developer velocity. Global Compatibility: Fully compatible with federated repository setups, ensuring a consistent policy framework everywhere. Unlock Scale Barriers Fully Automated: A “set-it-and-forget-it” policy engine that runs automatically, requiring no manual intervention. Granular Control: Policies are project-scoped, allowing different teams and services to set archiving rules that make sense for their specific compliance and operational needs. Architecture The following is a schematic high level architecture of such a deployment. --- # Azure URL: https://jfrog.com/reference-architecture/self-managed/deployment/azure/ > Deployment recommendations for the JFrog Platform on Microsoft Azure. Covers AKS for compute, Azure Blob Storage for filestore, Azure Database for PostgreSQL Flexible Server, and high availability configurations. Overview When deploying on Azure, consider the following recommendations. Diagram Compute Use Azure Kubernetes Service (AKS) for running the JFrog Platform applications. Storage In Azure, you are required to create an Azure Storage account. A Standard general-purpose v2 account type is enough. Server Local Storage High-performance local storage is essential for Artifactory’s cache-fs, as it significantly affects overall Artifactory performance. See the recommended storage specifications in the Sizing section. Filestore Use Azure Blob Storage to store the Artifactory binaries. Database Use Azure Database for PostgreSQL - Flexible Server as the applications’ database. Use a High availability (Reliability) in Azure Database for PostgreSQL - Flexible Server deployment for higher durability in case of a zone or instance outage. See recommended storage specifications in the Sizing section. --- # CI - CD Separation URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/ci-cd-separation/ > CI/CD separation architecture for JFrog Platform SaaS deployments. Covers separate CI and CD sites across cloud providers, federation for package promotion, security isolation, compliance requirements, and organizational separation of concerns. CI - CD Separation Fully managed JFrog Platform SaaS sites/regions Separate JFrog Platform sites are used for different concerns CI (Continuous Integration): R&D development and release lifecycle management. Building, testing and releasing (ops focus on promotion and cleanup) CD (Continuous Delivery or Deployment): Operations for distribution and deploying to production (ops focus on compliance and archiving) Each site is separately owned and managed by its respective team(s) Using Federation to promote only production ready packages from CI to CD site or region The sites can be in different cloud providers and regions as the federation is a JFrog feature and not related to the cloud provider The CD site is the single source of all production environments’ binaries Why? Why separate CI servers and sites from CD servers and sites? CI and CD teams often have different workflows and infrastructure needs, so separate sites let each focus on their priorities Enforcing separation of concerns improves security by isolating build and deployment stages, reducing risk from changes or breaches Compliance and regulatory mandates may require production environments (CD) to be operated with stricter controls than development (CI) Geographic, organizational, or departmental boundaries might dictate separate CI and CD locations or ownership High-frequency CI workloads can overwhelm a shared site; splitting sites ensures scalability and stability for both environments Restricting access to CD sites minimizes the risk of unauthorized or accidental production releases Keeping production binaries solely in the CD site improves auditability and simplifies compliance Architecture The following is a schematic high level architecture of such a topology with two organizations having a dedicated CI JPD each, federating production releases to a common CD site. --- # CI - CD Separation URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/ci-cd-separation/ > CI/CD separation architecture for self-managed JFrog Platform deployments. Covers separate CI and CD sites, federation for package promotion, security isolation, compliance requirements, and organizational separation of concerns. CI - CD Separation Separate JFrog Platform deployments used for different concerns CI (Continuous Integration): R&D development and release lifecycle management. Building, testing and releasing (ops focus on promotion and cleanup) CD (Continuous Delivery or Deployment): Operations for distribution and deploying to production (ops focus on compliance and archiving) Each site is separately owned and managed by its respective team(s) Using Federation to promote only production ready packages from CI to CD JPD The CD JPD is the single source of all production environments Why? Why separate CI servers and sites from CD servers and sites? CI and CD teams often have different workflows and infrastructure needs, so separate sites let each focus on their priorities Enforcing separation of concerns improves security by isolating build and deployment stages, reducing risk from changes or breaches Compliance and regulatory mandates may require production environments (CD) to be operated with stricter controls than development (CI) Geographic, organizational, or departmental boundaries might dictate separate CI and CD locations or ownership High-frequency CI workloads can overwhelm a shared site; splitting sites ensures scalability and stability for both environments Restricting access to CD sites minimizes the risk of unauthorized or accidental production releases Keeping production binaries solely in the CD site improves auditability and simplifies compliance Architecture The following is a schematic high level architecture of such a topology with two organizations having a dedicated CI JPD each, federating production releases to a common CD JPD. --- # GCP Sizing URL: https://jfrog.com/reference-architecture/self-managed/deployment/sizing/gcp/ > GCP infrastructure sizing recommendations for self-managed JFrog Platform deployments. Includes GKE instance types for Artifactory, Nginx, Xray, JAS, and Cloud SQL PostgreSQL configurations across different sizing templates. Last updated: June 2026 GCP Sizing When deploying a self-managed deployment of the JFrog Platform on GCP, it is important to consider the hardware and sizing requirements to ensure optimal performance and scalability. The following guidelines are recommended for sizing your GCP infrastructure. Artifactory NOTES: Each Artifactory replica should run in its own instance (prefer a dedicated node pool) The Nginx here refers to the instance bundled with Artifactory Each Nginx replica should run in its own instance (prefer a dedicated node pool) If using an ingress controller, you can omit the bundled Nginx, but should determine the appropriate number of ingress controller replicas for your deployment If using an ingress controller Set artifactory.ingress.enabled (or artifactory.artifactory.ingress.enabled when using the jfrog-platform chart) to true Set artifactory.nginx.enabled (or artifactory.artifactory.nginx.enabled when using the jfrog-platform chart) to false JFrog Distribution can run on the same nodes as Artifactory If you are enabling Platform Federation and/or AppTrust, use the Artifactory node pool rows marked (Federation / AppTrust). The higher vCPU counts provide headroom for the additional JFrog services. Size Template Small Medium Large XLarge 2XLarge Number of Artifactory Replicas 1 2 3 4 6 Number of Nginx Replicas 1 2 2 2 3 Artifactory node pool instance n4-standard-8 n4-standard-8 n4-standard-16 n4-standard-16 n4-standard-16 vCPU 8 8 16 16 16 Memory 32 32 64 64 64 Artifactory node pool instance (Federation / AppTrust) c4d-highcpu-16 c4d-highcpu-16 c4d-highcpu-32 c4d-highcpu-32 c4d-highcpu-32 vCPU 16 16 32 32 32 Memory 32 32 64 64 64 Nginx node pool instance c4d-highcpu-4 c4d-highcpu-4 c4d-highcpu-4 c4d-highcpu-8 c4d-highcpu-8 vCPU 4 4 4 8 8 Memory 8 8 8 16 16 Cloud SQL PostgreSQL instance Custom Custom Custom Custom Custom vCPU 8 16 32 48 64 Memory 32 64 128 192 256 Max connections 100 200 600 2000 5000 Xray NOTES: Each Xray replica should run in its own instance (prefer a dedicated node pool) Xray has HPA enabled, so more instances should be available if needed If running JAS, it’s recommended to use a dedicated node pool for it to protect Xray and Artifactory pods Size Template Small Medium Large XLarge 2XLarge Number of Xray Replicas 1 2 2 2 3 Number of RabbitMQ Replicas 1 3 3 3 3 Xray node pool instance c4d-highcpu-8 n4-standard-8 n4-standard-8 n4-standard-8 n4-standard-8 vCPU 8 8 8 8 8 Memory 15 32 32 32 32 RabbitMQ node pool instance c4d-highcpu-4 c4d-highcpu-4 c4d-highcpu-4 c4d-highcpu-4 c4d-highcpu-4 vCPU 4 4 4 4 4 Memory 7 7 7 7 7 JAS node pool instance n4-standard-8 n4-standard-8 n4-standard-8 n4-standard-8 n4-standard-8 vCPU 8 8 8 8 8 Memory 32 32 32 32 32 PostgreSQL RDS instance Custom Custom Custom Custom Custom vCPU 4 8 16 32 48 Memory 16 32 64 128 192 Max connections 200 500 600 1200 2000 Storage See Storage Specifications for details on storage requirements and recommendations. --- # Network URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/network/ > Network considerations for JFrog Platform deployments including IP address space requirements, load balancer configuration, firewall rules, network ports for Artifactory, Xray, and Distribution, and internal service communication. Network Considerations This section describes networking requirements and recommendations for JFrog Platform Deployments Networking Routable IP Space and Cluster AZ Deployment for each Component The Load Balancer will be a layer 7 public facing load balancer and must have routable external IP address space for incoming and outgoing traffic When the JFrog Platform is deployed in three Availability Zones (HA), you need three /24 network IP address space to house JFrog Platform services such as Artifactory, Xray, Distribution, etc. Please note that the JFrog Platform currently supports only IP address-based communication internally between the services in a single JFrog Platform deployment. This means that it does not support DNS names internally between the services. Firewall The routes between the Load Balancer and JFrog Platform Artifactory should not be blocked. The network ports that need to be opened are listed in JFrog docs Network Requirements for JFrog Products Internal Ports The JFrog Platform requires the following internal network ports to be opened up for Platform Services to communicate between them. All services need port 8082 accessible Artifactory requires also port 8081 The external access to the platform would be on port 443 through a load balancer, exposed to external traffic. --- # Archiving URL: https://jfrog.com/reference-architecture/self-managed/use-cases/archiving/ > JFrog Smart Archiving solution for managing artifact lifecycle in self-managed deployments. Covers automated archiving policies, compliance and security preservation, operational efficiency improvements, and cost optimization for inactive artifacts. Smart Archiving JFrog Smart Archiving is a solution designed to manage the lifecycle of development artifacts that are no longer in active use but must be retained for compliance, audit, or historical purposes. It provides organizations with the flexibility to define granular policies that determine which packages to archive and when. This process is fully automated and ensures that all essential metadata, security attestations, and compliance data are preserved and remain fully accessible for restores if and when needed. Why Smart Archiving? The Cost of “Digital Dust” As development repositories grow, they accumulate “Digital Dust”—a build-up of obsolete releases, end-of-life artifacts, and orphaned dependencies. This unmanaged data, a lot of which cannot be simply deleted, creates significant and escalating business friction. The “cost” of this dust is not just financial; it impacts the entire organization: Productivity Drain: Developers face slowdowns as CI/CD pipelines lag. Locating current, trusted artifacts becomes a “needle in a haystack” problem, wasting valuable engineering time. Performance Brake: Bloated repositories slow down release cycles, degrade overall system performance, and can increase failure rates in production. Security & Compliance Holes: Every unmanaged artifact expands the potential attack surface. This “dust” creates a significant, unmonitored risk of failed audits and security vulnerabilities. Financial Tax: The direct cost of storing and transferring this ever-growing, inactive data is a continuous and unnecessary financial drain. The Solution: Three Pillars of Trust Smart Archiving is designed to turn this “Digital Dust” into a managed, compliant, and trusted archive. The solution is built on three core pillars: Ensure Bulletproof Compliance & Security Full Traceability: Generates detailed reports (e.g., “what would be archived?” and “what was archived?”) to provide a clear audit trail. Dry Run Capability: Allows teams to test and validate policies without moving any data, ensuring policy accuracy before execution. Seamless Retrieval: All metadata and evidence are preserved and remain available, ensuring you can prove compliance instantly. Improve Operational Efficiency Optimized Repositories: By moving inactive data, active repositories remain lean, fast, and responsive. Performance Gains: Directly reduces CI/CD pipeline friction and improves overall developer velocity. Global Compatibility: Fully compatible with federated repository setups, ensuring a consistent policy framework everywhere. Unlock Scale Barriers Fully Automated: A “set-it-and-forget-it” policy engine that runs automatically, requiring no manual intervention. Granular Control: Policies are project-scoped, allowing different teams and services to set archiving rules that make sense for their specific compliance and operational needs. Architecture The following is a schematic high level architecture of such a deployment. --- # GCP URL: https://jfrog.com/reference-architecture/self-managed/deployment/gcp/ > Deployment recommendations for the JFrog Platform on Google Cloud Platform (GCP). Covers GKE for compute, Google Cloud Storage for filestore, Cloud SQL for PostgreSQL, and high availability deployment configurations. Overview When deploying on GCP, consider the following recommendations. Diagram Compute Use Google Kubernetes Engine (GKE) for running the JFrog Platform applications. Storage Server Local Storage High-performance local storage is essential for Artifactory’s cache-fs, as it significantly affects overall Artifactory performance. See the recommended storage specifications in the Sizing section. Filestore Use a Google Cloud Storage (GCS) bucket to store the Artifactory binaries. Database Use Google Cloud SQL for PostgreSQL as the applications’ database. Use a Google Cloud SQL PostgreSQL high availability deployment for higher durability in case of an instance or zone failure. See recommended storage specifications in the Sizing section. --- # High Availability URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/high-availability/ > High availability configuration for the JFrog Platform using cluster mode deployment. Covers Kubernetes deployment with three instances across availability zones, horizontal scalability, shared storage and database, and anti-affinity configurations. High Availability For the highest availability and durability, the JFrog Platform services need to be deployed in a cluster mode, where each cluster member configured in a clustered environment will provide High Availability. When running in a K8s environment, configure three instances of the Artifactory, Xray and Distribution services. When adding additional cluster members, this provides horizontal scalability to this platform. Ideally, the cluster members are deployed in three Availability zones as defined by the underlying Kubernetes cluster deployment. The storage and database deployment is shared across all cluster members. Note that there should be separate deployment of a database instance for Artifactory and Xray. Terraform Example See an example in the JFrog Charts repository, for a Terraform configuration that creates the necessary AWS infrastructure and services required to run the JFrog Platform and follow the guidelines above. In this example, if you choose the large sizing, it will create three instances of the Artifactory pod with anti-affinity between them, so they run on separate Kubernetes nodes. --- # JFrog Security URL: https://jfrog.com/reference-architecture/security/ > Comprehensive DevSecOps and software supply chain security solutions. Learn about JFrog Security's end-to-end protection from OSS protection and source code analysis to binary scanning and runtime monitoring, with seamless CI/CD integration. Overview DevSecOps and the Software Supply Chain To address today’s evolving threats, organizations need DevSecOps building security into every stage of the software lifecycle. Open-source code, automated CI/CD, and flexible runtimes all bring risks requiring continuous, proactive protection. JFrog Security delivers comprehensive supply chain security, from development to production. With integrated DevSecOps, you protect applications, dependencies, and infrastructure at every stage. Core Security Principles End-to-End Protection Security is embedded throughout the SDLC (Software Development Life Cycle), from OSS protection, source code analysis, and binary analysis to runtime monitoring. This comprehensive approach ensures vulnerabilities and threats are identified and mitigated at every stage: OSS Protection: Prevent malicious packages from entering your development environment Source Code Analysis: Identify vulnerabilities and security issues in your codebase early Binary Analysis: Scan compiled artifacts and dependencies for known vulnerabilities Runtime Monitoring: Continuous visibility and protection for applications in production Seamless Integration Works natively with CI/CD pipelines, package registries, and DevOps tools. JFrog Security integrates seamlessly into your existing workflows without disrupting development velocity: Native integration with popular CI/CD platforms (Jenkins, GitLab CI, GitHub Actions, Azure DevOps, etc.) Deep integration with package registries (npm, Maven, PyPI, Docker, Helm, and more) Works with existing DevOps tools and workflows Minimal configuration required for immediate value Automated Security & Compliance Continuous scanning, risk assessment, and policy enforcement. Security policies are automatically enforced throughout the development lifecycle: Continuous Scanning: Automated vulnerability detection across all packages and dependencies Risk Assessment: Prioritize security issues based on impact and exploitability Policy Enforcement: Automated blocking of vulnerable or non-compliant artifacts Compliance Reporting: Automated compliance checks and reporting for regulatory requirements Next Steps & In-Depth Resources To deepen your understanding and begin implementing JFrog Security, explore the following: Step-by-step Implementation Guides API References and Usage Examples Configuration and Integration Tutorials Best Practices and Security Policies Access all resources, documentation, and tutorials in the JFrog Security User Guide. --- # Main Site with Edges URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/main-site-with-edges/ > Main site with edge nodes architecture for JFrog Platform SaaS. Covers central SaaS site with Artifactory Edge sites (SaaS or self-hosted), release bundles distribution, smart remote repositories, and read-only edge configurations for remote locations. Main Site with Edges A fully managed central JFrog Platform SaaS site One or more JFrog Artifactory Edge self-hosted or JFrog SaaS sites Packages are distributed from the main site to edge sites using release bundles, or accessed via Smart Remote repositories that proxy and cache repositories from the main site at the edge sites. Packages in the edges are read only (immutable), and consumed by the edge sites’ clients Ideal for scenarios where software packages are developed and pushed to a main site, then need to be consumed at remote locations—such as by other organizational teams, customers, or vendors. Limitations Artifactory Edge comes with limited capabilities. Review the comparison table to understand them better. Architecture The following is a schematic high level architecture of such a topology --- # Main Site with Edges URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/main-site-with-edges/ > Main site with edge nodes architecture for self-managed JFrog Platform deployments. Covers central Artifactory deployment with remote Artifactory Edge sites, release bundles distribution, smart remote repositories, and read-only edge configurations. Main Site with Edges A central JFrog Platform deployment to be used by a central organization This can be also a multi-site deployment where one of the sites is used as the main site, which is the source of truth Multiple JFrog Artifactory Edge sites used by remote organizations’ teams Using release bundles to push packages to edges or Smart Remote repositories on the edges to pull from the main site Packages in the edges are read only (immutable), and consumed by the edge sites’ read-only clients Limitations Artifactory Edge comes with limited capabilities. Review the comparison table to understand them better. Architecture The following is a schematic high level architecture of such a topology --- # Storage Specifications URL: https://jfrog.com/reference-architecture/self-managed/deployment/sizing/storage/ > Storage specifications and requirements for JFrog Platform deployments. Covers local disk requirements for Artifactory and Xray nodes, PostgreSQL disk sizing, IOPS, and throughput recommendations across different sizing templates. Storage Specifications NOTES: For Artifactory, the node disk is the local disk used mainly for cache and temp storage For Xray, the node disk is the local disk used mainly for package scanning Disk types should be SSD Disk size in GB Throughput is in MB/sec Artifactory Size Template Small Medium Large XLarge 2XLarge Artifactory nodes disk size 500 500 1000 1000 1000 IOPS 3000 3000 6000 6000 6000 Throughput 500 500 1000 1000 1000 PostgreSQL disk size 1/3 of Artifactory filestore - - - - IOPS 4000 6000 10000 12000 20000 Throughput 500 600 800 1000 1500 Xray Size Template Small Medium Large XLarge 2XLarge Xray nodes disk size 100 100 200 200 200 IOPS 3000 3000 6000 6000 6000 Throughput 500 500 1000 1000 1000 RabbitMQ nodes disk size 100 100 100 100 100 IOPS 3000 3000 3000 3000 3000 Throughput 500 500 500 500 500 JAS nodes disk size 300 300 300 300 300 IOPS 3000 3000 3000 3000 3000 Throughput 500 500 500 500 500 PostgreSQL disk size 500 500 800 1000 2500 IOPS 4000 6000 6000 8000 12000 Throughput 500 600 600 1000 1000 --- # Database URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/database/ > Database considerations for the JFrog Platform including PostgreSQL recommendations, high availability configurations, database sizing, tuning for high loads, and failover strategies for both application-supported and vendor-supported HA. Database The JFrog platform requires a relational database to store and manage the state and metadata of its managed Artifacts. JFrog recommends using PostgreSQL database for its Platform services. PostgreSQL offers high availability (active - passive with failover in supporting providers), scaling and reliability. Configuration of Database connections is done in system.yaml. Tuning for High Load See Database tuning for high loads in Artifactory. Artifactory Database Sizing Refer to Artifactory Database Sizing. Database High Availability Considerations There are two options to use a high availability (HA) database. In the case of the JFrog Platform, the database HA is active - passive where in case of a failure, the passive instance is promoted to primary and the application moves to use the new primary replica. Application Supported HA with Failover Artifactory set up to use the PostgreSQL database in HA. Xray set up to use the PostgreSQL database in HA. Vendor Supported HA with Failover In supported platforms and providers, it’s possible to use a highly available DB deployment in an active - passive with failover configuration. Such a setup has a separate, standby replica of the database. In case of a failure, an automatic promotion of the standby replica to primary is done, and the DNS or IP of the database is updated to point to the new primary replica. See AWS RDS multi zone HA with failover deployment, for example. --- # Hybrid URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/hybrid/ > Hybrid deployment architecture combining JFrog SaaS and self-hosted sites. Covers JFrog Bridge for secure connectivity, distribution and federation between SaaS and on-premises, edge sites, and CI/CD separation topologies. Hybrid: JFrog SaaS with Self Hosted A central JFrog Platform site, which can be deployed as either a fully managed JFrog SaaS service or as a self-hosted instance Optionally, one or more JFrog Artifactory Edge sites (either SaaS or self-hosted) to support distributed teams or remote locations Optionally, additional JFrog Platform sites (SaaS or self-hosted) for further scalability, redundancy, or regional requirements Artifacts can be distributed from the main site to edge sites using release bundles, or accessed via Smart Remote repositories that allow edge sites to proxy and cache content from the main site Common use cases include: Needing to self-host digital assets while still sharing or distributing them with other organizational teams, customers, or vendors Requiring on-premises storage of digital assets, but also maintaining an off-premises copy for compliance, business continuity, or disaster recovery purposes JFrog Bridge Self-hosted sites are often unreachable from JFrog SaaS because of firewalls or network policy. JFrog Bridge provides secure connectivity for Distribution, Federation, and related hybrid workflows. Architecture There are many combinations of JFrog SaaS and self-hosted sites. A few examples are: SaaS as the main site Self-hosted edges (with JFrog Distribution and/or Smart Repositories) Self-hosted CI instances with federation of only relevant repositories. It can be used as a CI - CD separation topology Self-hosted as the main site SaaS as the CD site with federation of only relevant repositories. It can be used as a CI - CD separation topology SaaS site as data backup (with replication or federation) The following is a schematic high level architecture of such a topology --- # Hybrid URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/hybrid/ > Hybrid deployment architecture combining JFrog SaaS and self-hosted sites. Covers JFrog Bridge for secure connectivity, distribution and federation between SaaS and on-premises, edge sites, and CI/CD separation topologies. Hybrid: JFrog SaaS with Self Hosted A central JFrog Platform site, which can be deployed as either a fully managed JFrog SaaS service or as a self-hosted instance Optionally, one or more JFrog Artifactory Edge sites (either SaaS or self-hosted) to support distributed teams or remote locations Optionally, additional JFrog Platform sites (SaaS or self-hosted) for further scalability, redundancy, or regional requirements Artifacts can be distributed from the main site to edge sites using release bundles, or accessed via Smart Remote repositories that allow edge sites to proxy and cache content from the main site Common use cases include: Needing to self-host digital assets while still sharing or distributing them with other organizational teams, customers, or vendors Requiring on-premises storage of digital assets, but also maintaining an off-premises copy for compliance, business continuity, or disaster recovery purposes JFrog Bridge Self-hosted sites are often unreachable from JFrog SaaS because of firewalls or network policy. JFrog Bridge provides secure connectivity for Distribution, Federation, and related hybrid workflows. Architecture There are many combinations of JFrog SaaS and self-hosted sites. A few examples are: SaaS as the main site Self-hosted edges (with JFrog Distribution and/or Smart Repositories) Self-hosted CI instances with federation of only relevant repositories. It can be used as a CI - CD separation topology Self-hosted as the main site SaaS as the CD site with federation of only relevant repositories. It can be used as a CI - CD separation topology SaaS site as data backup (with replication or federation) The following is a schematic high level architecture of such a topology --- # Observability URL: https://jfrog.com/reference-architecture/observability/ > Initial observability guide for the JFrog Platform covering monitoring, logging, and metrics. Learn about built-in SaaS observability features via MyJFrog portal and requirements for self-hosted deployments including infrastructure monitoring and application metrics. Overview Comprehensive observability of your JFrog Platform is essential for maintaining optimal performance, reliability, and security. While this can be achieved in both self-hosted and SaaS, JFrog SaaS significantly simplifies this critical operational aspect. JFrog SaaS Observability When using JFrog SaaS, observability is built-in through the JFrog Platform APIs and UI and also through the MyJFrog portal. JFrog Observability Features Key monitoring features Platform services status (Self hosted only) Storage status and allocation SaaS logs streaming (SaaS only) Readiness and Liveness probes See more in the Monitoring and Logging help page. MyJFrog Portal Some of the key features of the MyJFrog portal include: Real-time service health monitoring Resource utilization metrics Automated alerts and notifications Usage trends and statistics Security status and compliance reports Audit logs and access control The MyJFrog portal serves as your centralized observability dashboard, eliminating the need for complex monitoring setup and maintenance. Self-Hosted Observability Requirements If running a self-hosted JFrog Platform, you’ll need to implement and manage: Infrastructure Monitoring Kubernetes cluster system and application health Node resources (CPU, memory, disk) monitoring Network connectivity Storage providers Database health Platform Availability Readiness and Liveness probes System logs configuration Log analytics setup Application Metrics & Integration Tools To achieve comprehensive observability in a self-hosted JFrog Platform deployments, you’ll need to collect application metrics, integrate monitoring tools, and configure alerting and retention policies. Typical observability requirements include: Metrics collection (using OpenMetrics format) Integration with monitoring tools such as Prometheus and Grafana Log aggregation using solutions like Loki, Fluentd or Filebeat Alert configuration and automated notifications Data visualization and dashboard setup Historical data retention and policy management Additional monitoring services as needed A popular example combines Prometheus for metrics collection, Loki for log aggregation, and Grafana for dashboards—in Kubernetes deployments, see the log-analytics-prometheus example for a ready-to-use setup. Best Practices JFrog SaaS Regularly review MyJFrog dashboards Configure notification preferences Monitor usage patterns and trends Track security compliance Self-Hosted Implement comprehensive monitoring Set up proactive alerts Configure log aggregation Maintain historical metrics Define retention policies --- # Private Datacenter URL: https://jfrog.com/reference-architecture/self-managed/deployment/private-datacenter/ > Deployment guide for the JFrog Platform in private data centers. Covers regulatory compliance, data sovereignty, air-gapped environments, existing infrastructure optimization, and performance requirements for on-premises deployments. Overview Private data center deployments remain essential for organizations with specific regulatory, security, operational, or economic requirements that cannot be met by public cloud services. Understanding these key scenarios helps determine when on-premises JFrog Platform deployment is necessary. When Private Data Centers Are Required Regulatory Compliance and Data Sovereignty Strict Regulatory Requirements Financial Services: PCI DSS, SOX, banking regulations requiring data within specific boundaries Healthcare: HIPAA, GDPR compliance for protected health information (PHI) Government and Defense: FedRAMP, ITAR restrictions, classified data handling Regional Compliance: Local data protection laws requiring data residency Data Sovereignty Legal requirements to keep data within national borders Contractual obligations regarding data location Export control and intellectual property protection requirements Security and Air-Gapped Environments Maximum Security Requirements Classified or sensitive workloads requiring complete isolation Critical infrastructure with stringent security standards Zero external connectivity requirements for security reasons Air-gapped networks with no internet access Existing Infrastructure Investment Legacy Infrastructure Optimization Substantial existing investments in data center infrastructure Depreciation schedules requiring continued on-premises operation Deep integration with existing enterprise systems (ERP, CRM, manufacturing) Specialized hardware requirements not available in public cloud Performance and Latency Requirements Ultra-Low Latency Needs High-frequency trading requiring microsecond response times Real-time manufacturing and industrial control systems Edge computing applications near data sources Large-scale data processing where cloud transfer is impractical Economic and Operational Control Cost and Control Factors Large-scale deployments where private infrastructure is more cost-effective Predictable workloads with steady resource requirements Long-term operations where ownership is more economical Need for complete control over infrastructure, updates, and maintenance schedules Key Considerations Infrastructure Requirements High-availability infrastructure with redundancy and disaster recovery Secure network architecture and access controls Sufficient compute, storage, and network capacity for growth Operational Requirements In-house expertise for administration and troubleshooting Regular security assessments and compliance auditing Integration with existing IT operations and support procedures Future Flexibility Architecture that supports eventual hybrid or cloud migration Container orchestration and modern DevOps practices Unified management across multiple deployment models Private data center deployments provide the control, security, and compliance capabilities required by organizations with specific requirements while maintaining flexibility for future architectural evolution. --- # Disaster Recovery URL: https://jfrog.com/reference-architecture/disaster-recovery/ > Disaster recovery strategies and best practices for the JFrog Platform. Learn about multi-site deployments, DR playbooks, recovery objectives (RTO/RPO), and how to ensure business continuity during unexpected disruptions. Overview Disaster recovery (DR) is essential for business continuity during unexpected disruptions. This page summarizes the main concerns and components of DR for software production. What is Disaster Recovery? Disaster recovery covers the strategies and processes to restore essential software services after events like hardware failures, cyber attacks, natural disasters, or human error. The goal is to recover systems, applications, and data quickly, minimizing downtime and data loss. Core Components Effective DR planning includes: Regular backups of critical data/configurations Redundant infrastructure to avoid single points of failure Documented recovery procedures for disaster scenarios Frequent testing to ensure readiness Recovery Objectives DR plans should define: RTO (Recovery Time Objective): Max time to restore services RPO (Recovery Point Objective): Max acceptable data loss These set expectations for restoration and data protection. Organizations should evaluate their DR needs against industry-standard disaster recovery tiers (Tier 0-7), which provide a framework for understanding different levels of data protection, recovery capabilities, and associated costs. Beyond Restoration DR must also ensure: Data integrity during/after recovery Security controls remain effective Compliance with regulations A strong DR plan reduces risk, protects reputation, and helps meet SLAs. JFrog Platform Disaster Recovery The JFrog Platform is critical for software delivery, so high availability is vital. Effective DR for JFrog combines a robust multi-site deployment with a clear DR playbook for different scenarios. If limited to a single site, use JFrog SaaS for built-in regional DR and a 99.9% SLA. A multi-site deployment runs JFrog Platform across multiple locations, connected by access federation (for users, permissions, security) and repository federation (for artifacts and metadata). If one site fails, another can take over, minimizing downtime and data loss. A DR playbook is essential for guiding recovery from: Site/data center outages Data corruption or deletion Security incidents or ransomware Network failures See the DR playbook for details. Combining geo-distributed multi-site deployment with a scenario-based DR playbook keeps the JFrog Platform available, secure, and compliant during disruptions. Architecture A robust JFrog Platform should use two or more geographically distinct sites with access and repository federation. Sites can be JFrog SaaS (recommended), self-hosted, or hybrid. Multi-Site DR Options JFrog SaaS: Active-passive, Active-active Self-Hosted: Active-passive, Active-active Single Site DR JFrog SaaS (Recommended): Single-site SaaS includes regional DR with 24h RTO and 1h RPO. Self-Hosted: RTO depends on restore time from backup; RPO depends on backup frequency. Regular backups are needed: Artifactory Backup: Backup guide A clear DR playbook is also required. See the DR playbook for more. --- # Hybrid Manufacturing URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/hybrid-manufacturing/ > Hybrid manufacturing deployment architecture with JFrog SaaS and manufacturing sites. Covers PrivateLink connections, central SaaS site for software releases, local Artifactory Edge at manufacturing plants, and smart remote repositories for pulling releases. Hybrid: JFrog SaaS with Manufacturing Sites Manufacturing enterprises are made up of One or more software development sites One or more manufacturing sites A firewall between all organization’s sites and the internet Using the JFrog PrivateLink feature to connect the customer’s private cloud account to JFrog SaaS in the selected region A central JFrog SaaS site used by all organizations in the company (can be multiple sites) Software releases are pushed to JFrog SaaS Manufacturing plants are running local Artifactory Edge (with Smart Remote Repositories) and pull the necessary software releases from JFrog SaaS as needed JFrog Bridge Self-hosted sites are often unreachable from JFrog SaaS because of firewalls or network policy. JFrog Bridge provides secure connectivity for Distribution, Federation, and related hybrid workflows. Architecture The following is a schematic high level architecture of such a topology --- # Hybrid Manufacturing URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/hybrid-manufacturing/ > Hybrid manufacturing deployment architecture with JFrog SaaS and manufacturing sites. Covers PrivateLink connections, central SaaS site for software releases, local Artifactory Edge at manufacturing plants, and smart remote repositories for pulling releases. Hybrid: JFrog SaaS with Manufacturing Sites Manufacturing enterprises are made up of One or more software development sites One or more manufacturing sites A firewall between all organization’s sites and the internet Using the JFrog PrivateLink feature to connect the customer’s private cloud account to JFrog SaaS in the selected region A central JFrog SaaS site used by all organizations in the company (can be multiple sites) Software releases are pushed to JFrog SaaS Manufacturing plants are running local Artifactory Edge (with Smart Remote Repositories) and pull the necessary software releases from JFrog SaaS as needed JFrog Bridge Self-hosted sites are often unreachable from JFrog SaaS because of firewalls or network policy. JFrog Bridge provides secure connectivity for Distribution, Federation, and related hybrid workflows. Architecture The following is a schematic high level architecture of such a topology --- # Storage URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/storage/ > Storage considerations for Artifactory including local storage for cache, filestore options (object storage, NFS), direct cloud storage upload, filestore sharding, storage sizing, and performance requirements for production deployments. Storage Considerations Artifactory manages binaries in a filestore and their metadata in a relational database. Each binary has a unique checksum calculated during the upload, and the checksum and its metadata (filename, creation dates, package metadata, etc.) are stored in the database. Read more on the checksum-based storage. Storage Layers There are two layers of storage Artifactory manages Local storage: The local disk on the server running Artifactory itself. Used for Local downloads cache. This uses the local node’s disk and not an external disk. In the case of Kubernetes, this is an emptyDir volume Eventual (not recommended) for temporary storage of uploaded binaries until they are fully uploaded to the final filestore IMPORTANT: Avoid using the eventual storage. Use the direct upload solutions like the S3 direct upload If you must, when running in Kubernetes, don’t use the eventual on the local node storage but rather an external PVC so on a pod rescheduling, the data is not lost Filestore: An external storage for the final storage of Artifactory binaries This should not be in the server’s local disk but rather a dedicated network storage like object storage or NFS NOTE: If using NFS as Artifactory’s filestore, make sure it has high throughput and low latency. NFS is not recommended for high load environments. Local Storage Considerations The local disk on the server running Artifactory should be with the following specs: Type: SSD Size: 500GB for cache-fs, eventual and temp work More storage used for the cache-fs will improve download performance IOPS: 6000 or higher Throughput: 1000 MB/sec or higher Detailed specs for the local storage disks and performance can be found in the Sizing section of this guide. Filestore Storage Considerations There are many types of external storage that can be used for Artifactory as its Filestore. Some examples are: S3, EBS, etc. Following is a list of the common options to consider. Object Storage (recommended) JFrog Artifactory supports object storage providers like AWS S3, Google Cloud Storage and Azure Blob storage for the final storage of its binaries. The main benefit is a very robust, reliable, scalable and high performance storage. Artifactory can also harness these providers’ support for direct cloud storage download and direct cloud upload, which boosts performance and scale. Follow JFrog instructions on setting up the preferred object storage for your Artifactory. AWS S3 Google Cloud Storage Azure Blob storage Direct Cloud Storage Upload (recommended) The Direct Upload mechanism enables you to upload without the need to maintain persistent storage for the eventual directory. This mechanism may also allow for faster uploads, since there is less contention for disk IO, particularly when Artifactory is hosted on AWS. AWS S3 direct upload Google Cloud Storage direct upload Azure Blob storage direct upload IMPORTANT: The object storage bucket must be in the same region your Artifactory is running in. Filestore Sharding JFrog Artifactory can use multiple storage volumes with sharding between them, so you gain better durability and availability of the stored binaries. See instructions on setting up filestore sharding. NFS JFrog Artifactory can work with an external file storage like NFS or similar. Follow instructions for setting up NFS as filestore to use NFS as the filestore. The NFS is basically mounted to the local server’s file system as a volume and Artifactory is using it like a local filestore storage. Required specs: Sub ms to 5 ms latency Size: 1TB (NFS mount size must have enough storage to host all your binaries) IOPS: 6000 or higher Throughput: 1000 MB/sec or higher Filestore Sizing JFrog Artifactory holds all of your organization’s binary assets. As such, it will require a lot of storage and ideally, such that it can grow as needed. Cloud providers object storage like AWS S3 offer limitless storage. It’s recommended to allocate multiple terabytes for a production environment to begin with. Additional Information See Best Practices for Managing Your Artifactory Filestore for more information on Artifactory storage best practices. --- # Hybrid with JFrog Bridge URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/hybrid-jfrog-bridge/ > Hybrid SaaS and self-managed JPDs when inbound access to on-premises is blocked. Covers JFrog Bridge outbound tunnels, access and repository federation, Distribution to Edge, and links to official Bridge administration documentation. Hybrid with JFrog Bridge Hybrid JFrog deployments combine a JFrog Platform Deployment (JPD) in JFrog SaaS with self-managed JPDs on your premises, often behind corporate firewalls. Federated services need those sites to sync, but policies that block inbound connectivity to on-prem prevent self-managed JPDs from participating like internet-reachable sites. JFrog Bridge closes that gap: the self-managed Bridge Client opens outbound connections to the SaaS Bridge Server, forming a secure tunnel so platform traffic flows without inbound firewall exceptions. See the same documentation for installation, configuration, and operations. Bridge is supported with an Enterprise+ subscription. Network and security challenges Bridge addresses No inbound firewall exceptions: Federated features assume JPDs can reach each other; inbound denials to self-managed JPDs break that model. Bridge reverses direction—the Client initiates outbound HTTP to SaaS—avoiding inbound holes on your network. Avoiding heavy network plumbing: Site-to-site VPNs, peering, or private link add cost and operations. Bridge is an application-layer tunnel over outbound paths you typically already allow. Trust and egress: Forwarded API requests authenticate with your self-managed CA; Bridge can use the platform proxy defaults and per-bridge overrides. What Bridge enables (common scenarios) The SaaS JPD forwards requests over the encrypted Bridge path to the self-managed JPD: Access Federation — Identity and access management through the Bridge for consistent users, groups, and permissions. Repository Federation — Artifact synchronization where federated repositories span SaaS and self-managed JPDs across the firewall boundary. Distribution to self-managed Edge nodes — Release bundles and management traffic to Edge JPDs at protected sites. Central site, optional Edge sites, Smart Remote repositories, and release-driven workflows are covered on the general Hybrid page. Architecture Examples include SaaS as the main site (self-hosted edges, Distribution and/or Smart Repositories; self-hosted CI with selective federation, including CI - CD separation), or self-managed as the main site (SaaS as CD with selective federation; SaaS as backup). Where self-managed JPDs cannot accept inbound connections, JFrog Bridge makes federation and distribution viable. The schematic below matches the general Hybrid page (a Bridge-specific diagram may replace it later). --- # Hybrid with JFrog Bridge URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/hybrid-jfrog-bridge/ > Hybrid SaaS and self-managed JPDs when inbound access to on-premises is blocked. Covers JFrog Bridge outbound tunnels, access and repository federation, Distribution to Edge, and links to official Bridge administration documentation. Hybrid with JFrog Bridge Hybrid JFrog deployments combine a JFrog Platform Deployment (JPD) in JFrog SaaS with self-managed JPDs on your premises, often behind corporate firewalls. Federated services need those sites to sync, but policies that block inbound connectivity to on-prem prevent self-managed JPDs from participating like internet-reachable sites. JFrog Bridge closes that gap: the self-managed Bridge Client opens outbound connections to the SaaS Bridge Server, forming a secure tunnel so platform traffic flows without inbound firewall exceptions. See the same documentation for installation, configuration, and operations. Bridge is supported with an Enterprise+ subscription. Network and security challenges Bridge addresses No inbound firewall exceptions: Federated features assume JPDs can reach each other; inbound denials to self-managed JPDs break that model. Bridge reverses direction—the Client initiates outbound HTTP to SaaS—avoiding inbound holes on your network. Avoiding heavy network plumbing: Site-to-site VPNs, peering, or private link add cost and operations. Bridge is an application-layer tunnel over outbound paths you typically already allow. Trust and egress: Forwarded API requests authenticate with your self-managed CA; Bridge can use the platform proxy defaults and per-bridge overrides. What Bridge enables (common scenarios) The SaaS JPD forwards requests over the encrypted Bridge path to the self-managed JPD: Access Federation — Identity and access management through the Bridge for consistent users, groups, and permissions. Repository Federation — Artifact synchronization where federated repositories span SaaS and self-managed JPDs across the firewall boundary. Distribution to self-managed Edge nodes — Release bundles and management traffic to Edge JPDs at protected sites. Central site, optional Edge sites, Smart Remote repositories, and release-driven workflows are covered on the general Hybrid page. Architecture Examples include SaaS as the main site (self-hosted edges, Distribution and/or Smart Repositories; self-hosted CI with selective federation, including CI - CD separation), or self-managed as the main site (SaaS as CD with selective federation; SaaS as backup). Where self-managed JPDs cannot accept inbound connections, JFrog Bridge makes federation and distribution viable. The schematic below matches the general Hybrid page (a Bridge-specific diagram may replace it later). --- # Security URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/security/ > Security considerations for JFrog Platform deployments including TLS termination at load balancer or ingress, internal TLS between services, encryption at rest for storage and database, and secure database connections. Security Considerations Any access to the JFrog Platform should be done with https (TLS). TLS termination can be done in one of two common ways: At the Load Balancer which is in front of the platform deployment. Installation of the TLS certificates has to be done on the Load Balancer At the ingress controller. The main advantage of doing it like this is the ability to tie the configuration and management of the TLS setup (deployment and rotation)) with the K8s resources management using Kubernetes native methodologies like GitOps and Helm Charts For increased security, TLS can be enabled between the platform services. An internal signed certificate should be used for this setup. Secured connection should also be applied between the JFrog services, the database and storage. Storage All storage should be encrypted at rest. For example, see AWS EBS encryption. Database Database storage should also be configured with encryption at rest. For example, see AWS RDS encryption. Database connection should also be encrypted with TLS. For example, see AWS RDS TLS connection. JFrog Databases with TLS Artifactory Xray For JFrog Xray, there is also a way to setup TLS on RabbitMQ --- # Sizing URL: https://jfrog.com/reference-architecture/self-managed/deployment/sizing/ > Resource planning and sizing guidelines for the JFrog Platform. Covers t-shirt sizing templates (small to 2xlarge), infrastructure requirements for AWS, Azure, and GCP, storage specifications, and factors affecting performance and scalability. Overview Proper resource planning is crucial for optimal performance of your JFrog Platform deployment. The sizing requirements depend on various factors including usage patterns, number of artifacts, and enabled features. Key Sizing Factors Artifactory Considerations Request Volume - Number of concurrent downloads/uploads Storage Requirements - Total artifact storage needed Repository Count - Number and type of repositories Build Integration - CI/CD system integration load Security (Xray) Considerations Scan Volume - Number of artifacts being scanned Policies - Number of active security policies Watch Complexity - Number and complexity of watches Federation & Replication Push/Pull Replication - Number of repositories being replicated Federation Scale - Number of federated sites and repositories Network Bandwidth - Available bandwidth between sites Sizing Templates T-Shirt Sizing JFrog provides a set of predefined sizing templates to help you get started. These templates are designed to accommodate different use cases and loads, from small development environments to large enterprise deployments. Template Description Small Suitable for development/testing environments. Not for production! Medium Recommended for small production deployments Large Designed for medium enterprise production deployments Xlarge Designed for large enterprise-scale production deployments 2xlarge Designed for large enterprise-scale production deployments The following tables provide general guidelines for expected load handling capacity of each sizing template. Artifactory Sizing Templates Criteria Template Requests Per Minute (1) Concurrent Connections (2) Recommended Use Case small Up to 6000 Up to 100 Development/Testing medium Up to 50,000 Up to 500 Small Production large Up to 100,000 Up to 1,200 Medium Enterprise xlarge Up to 200,000 Up to 3,000 Large Enterprise 2xlarge Up to 500,000 Up to 6,000 Large Enterprise (1) Requests Per Minute (RPM): Represents the total number of HTTP requests handled collectively by all nodes in the Artifactory cluster within a minute. (2) Concurrent Connections: Refers to the total number of active HTTP threads serving requests across the entire Artifactory cluster at any given moment. Sizing can grow with additional replicas in the cluster (horizontal scaling) Xray Sizing Templates Criteria Template Number of Indexed Artifacts small Up to 100k indexed artifacts, and 1K artifacts/builds per day medium Up to 1M indexed artifacts, and 10k artifacts/builds per day large Up to 2M indexed artifacts, and 20k artifacts/builds per day xlarge Up to 10M indexed artifacts, and 50k artifacts/builds per day 2xlarge More than 10M indexed artifacts, and 50k artifacts/builds per day Sizing can grow with additional replicas in the cluster Notes These numbers are approximate guidelines and actual performance may vary based on: Types and numbers of artifacts being stored and transferred Network capacity and latency Storage performance Security scanning requirements Number and complexity of repositories For more system requirements and sizing recommendations, consult the JFrog Platform System Requirements documentation. Helm Charts Sizing Templates The JFrog Platform Helm chart provides predefined sizing templates to help you get started. Choose a template based on your use case and expected loads. Note: These templates are baselines, and you are encouraged to adjust them based on your specific needs and real usage patterns. Terraform Example See an example in the JFrog Charts repository, for a Terraform configuration that creates the necessary AWS infrastructure and services required to run the JFrog Platform and follow the guidelines above. You can choose the sizing while provisioning the infrastructure and deploy the JFrog Platform to it, so it’s ready to serve the required sized organization. Infrastructure Sizing With each sizing, you will need to consider the underlying infrastructure to match the required resources. NOTE: The JFrog Platform is fully supported on virtual machines; bare metal is not required. Sizing values represent compute cores—treat them as vCPUs on cloud and virtualized environments, or as CPU cores on bare metal. The numeric values are the same in both cases. Cloud instance types in the tables are examples; any instance or on-prem node meeting the vCPU/core and memory values is acceptable. See recommended infrastructure sizing for the JFrog Platform on AWS → Azure → GCP → NOTE: If you are deploying on-premise, use the same sizing templates as a reference. Allocate equivalent CPU cores on bare metal or vCPUs on VMs—the numeric values are the same. Additional Sizing Factors The proposed sizings in this document are set as a baseline. There are additional factors that impact the actual resources usage such as: Artifactory and Access Total number of repositories Total number of projects Total number of artifacts Per instance Per repository Size of a repository (number of artifacts) Total number of users Total number of groups and their sizes Total number of replications, federations and distributions Xray Total number of indexed (scanned) resources Total number of Xray workers Distribution Total number of release bundles Total number of files in a release bundle Frequency of distribution Total number of distribution targets Storage Specifications Local disk spec (IOPS, Throughput) Binarystore These factors will impact the JFrog Platform’s performance and should be used as additional factors when choosing a sizing. Custom sizing can be set to support even higher values where needed by customizing the Helm Chart’s sizings. --- # IoT Fleet Management URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/iot-fleet/ > IoT fleet management architecture using JFrog Connect with JFrog Platform SaaS. Covers device management, software deployment, security scanning, scalability for thousands of devices, and integration with CI/CD pipelines for IoT development. IoT Fleet Management JFrog Connect simplifies and secures the entire IoT devices fleet software development lifecycle. It unifies industry-leading artifact management, robust security, and enterprise-grade scalability for efficient, secure deployments of your IoT fleets’ software. Use JFrog Connect to manage your IoT devices and fleets, including: Device Management: Monitor and manage your devices, including remote access, diagnostics, and updates Software Deployment: Deploy software updates and patches to your devices, ensuring they are always running the latest versions Security: Ensure the security of your devices and software with built-in security features, including vulnerability scanning and compliance checks Scalability: Scale your IoT deployments easily, managing thousands of devices across multiple locations Integration: Seamlessly integrate with your existing CI/CD pipelines and DevOps tools for a streamlined development process Architecture The following is a schematic high level architecture of how JFrog Connect can be used to manage IoT fleets --- # Migration URL: https://jfrog.com/reference-architecture/self-managed/deployment/considerations/migration/ > Migration guide for moving the JFrog Platform to new infrastructure. Covers migration considerations including data size, hardware specifications, scalability, technology adoption, and migration to JFrog SaaS, along with the migration process for binaries and database. Overview As organizations grow and their IT or R&D infrastructure changes, it may become necessary to migrate the JFrog Platform from a legacy environment to a new deployment, typically on updated or different infrastructure. This page focuses on migrating Artifactory, the core component of the JFrog Platform and the primary location for storing company binaries. Migration Considerations When preparing for a migration, take into account the following key factors: Data Size: Total volume of artifacts and metadata. New Hardware Specifications: Capabilities and sizing of the target infrastructure. Look into the Sizing section for details Scalability: Ensuring the new environment supports anticipated growth. Technology Adoption: Leveraging new technologies or architectures as part of the migration. The recommended platform to install and run the JFrog Platform is Kubernetes. See the Runtime Platform section for this Migration To JFrog SaaS: There is an easy self service JFrog Cloud Migration solution. The benefits of JFrog SaaS are well described in the JFrog SaaS section Migration Process A successful migration involves moving the following critical components: Binaries: Data stored in Artifactory’s filestore. Database: Artifactory’s internal database, which contains: Binaries Metadata Application and services configurations For technical details and recommended approaches, refer to the Artifactory Migration Guide. --- # Subsidiaries and Vendors URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/subsidiaries-and-vendors/ > Multi-site architecture with a main JFrog Platform site for the parent organization and separate SaaS sites for subsidiaries or vendors. Covers separation of concerns, access isolation, operational boundaries, and selective federation or distribution between sites. Subsidiaries and Vendors: Separate Sites Organizations working with subsidiaries or vendors should isolate each group’s work on dedicated JFrog SaaS sites—separate from the main organization—to limit access, simplify permissions, and meet compliance, while allowing controlled artifact sharing when needed. How? A main JFrog Platform SaaS site for the parent organization only One or more dedicated SaaS sites for subsidiary and vendor work, separate from the main site A dedicated site is not necessarily one per entity. The parent organization chooses per site (separate site when a hard boundary is required) or per project on a shared dedicated site (each entity gets its own project for users, repositories, and permissions) Subsidiary and vendor work stays off the main site unless sites are explicitly connected; approved artifacts can flow via repository federation, release bundles, or similar patterns—akin to CI - CD separation, but driven by organizational boundaries Why? Keeps external and semi-autonomous parties off the parent organization’s full platform site while scoping each relationship as the parent defines Reduces operational complexity on the main site; the main site remains the system of record with selective outward sharing Considerations Choose site- vs. project-level separation per relationship; federation is subject to multi-site limitations Not every repository on a dedicated site needs to connect to the main site Architecture The following is a schematic high level architecture of such a topology --- # Subsidiaries and Vendors URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/subsidiaries-and-vendors/ > Multi-site architecture with a main JFrog Platform site for the parent organization and separate SaaS sites for subsidiaries or vendors. Covers separation of concerns, access isolation, operational boundaries, and selective federation or distribution between sites. Subsidiaries and Vendors: Separate Sites Organizations working with subsidiaries or vendors should isolate each group’s work on dedicated JFrog SaaS sites—separate from the main organization—to limit access, simplify permissions, and meet compliance, while allowing controlled artifact sharing when needed. How? A main JFrog Platform SaaS site for the parent organization only One or more dedicated SaaS sites for subsidiary and vendor work, separate from the main site A dedicated site is not necessarily one per entity. The parent organization chooses per site (separate site when a hard boundary is required) or per project on a shared dedicated site (each entity gets its own project for users, repositories, and permissions) Subsidiary and vendor work stays off the main site unless sites are explicitly connected; approved artifacts can flow via repository federation, release bundles, or similar patterns—akin to CI - CD separation, but driven by organizational boundaries Why? Keeps external and semi-autonomous parties off the parent organization’s full platform site while scoping each relationship as the parent defines Reduces operational complexity on the main site; the main site remains the system of record with selective outward sharing Considerations Choose site- vs. project-level separation per relationship; federation is subject to multi-site limitations Not every repository on a dedicated site needs to connect to the main site Architecture The following is a schematic high level architecture of such a topology --- # Multi Site Limitations URL: https://jfrog.com/reference-architecture/jfrog-saas/use-cases/multi-site/multi-site-limitations/ > Limitations and considerations for multi-site JFrog Platform SaaS deployments. Covers network connectivity requirements, latency impacts on federation, supported federation features, and configuration management recommendations using Infrastructure as Code. Limitations With the Multi Site architecture, JFrog federation features have some limitations to be aware of For federation to work, all JFrog Platform sites need to be able to reach each other over https. Without a bi-directional access, the federation will fail When federation is enabled, it is very much impacted by network latency, so need to allow time for a package in a the source federated repository to be visible in the remote target site’s repository Currently, only Access and Repository federation are supported. Objects outside of these two are not federated, and should be managed individually per each JFrog Platform site (like Projects, Repositories and Xray policies). JFrog plans to expand the Federation capabilities to the whole platform Features not covered by federation capabilities yet need to be configured separately on each site It’s recommended to use IaC tools like Terraform and harness the JFrog Terraform Providers to manage your platform’s configuration --- # Multi Site Limitations URL: https://jfrog.com/reference-architecture/self-managed/use-cases/multi-site/multi-site-limitations/ > Limitations and considerations for multi-site JFrog Platform deployments. Covers network connectivity requirements, latency impacts on federation, supported federation features, and configuration management recommendations using Infrastructure as Code. Limitations With the Multi Site architecture, JFrog federation features have some limitations to be aware of For federation to work, all JFrog Platform sites need to be able to reach each other over https. Without a bi-directional access, the federation will fail When federation is enabled, it is very much impacted by network latency, so need to allow time for a package in a the source federated repository to be visible in the remote target site’s repository Currently, only Access and Repository federation are supported. Objects outside of these two are not federated, and should be managed individually per each JFrog Platform site (like Projects, Repositories and Xray policies). JFrog plans to expand the Federation capabilities to the whole platform Features not covered by federation capabilities yet need to be configured separately on each site It’s recommended to use IaC tools like Terraform and harness the JFrog Terraform Providers to manage your platform’s configuration ---