Introduction

Imagine you’re a real estate agent, juggling countless client inquiries every day — each seeking quick answers about properties, prices, and availability. As much as you’d like to respond promptly to every message, the constant stream of requests can quickly become overwhelming. That’s where this real estate chatbot steps in.

This chatbot is designed to lighten the load for real estate agents by providing clients with instant, accurate information about the properties they’re interested in. Whether someone is passing by a property and wants details, or simply browsing and having a specific question, the chatbot is there to provide the right answers. If the client is ready to take things further and schedule a viewing, it seamlessly connects them with an agent for that next step.

Since this project was developed for a Latin American real estate company, WhatsApp is the natural platform choice — it’s the most widely used messaging app in the region for personal and business communication. This integration allows clients to quickly access property information while giving agents more time to focus on the other aspects of their work.

For those interested in the code behind this project, you can find the full implementation in my GitHub repository. Additionally, you can explore more of my work and projects on my portfolio site.

This blog series will mostly focus on the technical side of building this chatbot, covering key software development concepts and tools like Twilio, Flask, BERT, and LangChain. While it’s designed with software developers and data scientists in mind, I’ll do my best to make the content accessible for those who may not be as familiar with the technical aspects. Whether you’re a seasoned developer or just curious about how technology can streamline real estate processes, there’s something here for everyone.

Overview of the Architecture:

So, how does this chatbot actually work behind the scenes? Let’s walk through the journey from the moment a customer sends a message to the chatbot, all the way to receiving a response.

It all begins when a potential buyer reaches out via WhatsApp. Whether they’re asking about a specific property or just exploring their options, their message goes straight to the heart of our system. This is where Twilio comes in — a service that acts as the bridge between WhatsApp and our backend. Twilio allows the chatbot to receive and send messages in real time, managing communication seamlessly. In short, it’s the “messenger” of the whole operation, ensuring that every inquiry gets to where it needs to go.

Once Twilio captures the message, it passes it on to our server, built with Flask. Flask is a lightweight web framework that powers the chatbot’s backend, receiving the message and deciding what to do with it next. Here’s where things start to get smart.

The message is sent to a Roberta-based intent classifier — essentially a model trained to understand what the user’s message is about. It works by labeling the message into one of two categories: ‘contact agent’ or ‘other’.

• If the classifier identifies the message as ‘contact agent’, this means the user is interested in talking to a real estate agent directly, perhaps to schedule a viewing or inquire about more specific details. At this point, the chatbot automatically sends a notification to the agent, letting them know that a customer with a specific phone number is interested in a property. Simultaneously, the chatbot reassures the customer by sending a confirmation message, letting them know that the agent has been notified and will be in touch soon.
• On the other hand, if the classifier labels the message as ‘other’, this means the message is more general — perhaps the user is asking for more details about a property or a neighborhood. Here, the chatbot gets a little more sophisticated. The message is passed along to the LLM (Large Language Model), which uses RAG (Retrieval-Augmented Generation) to retrieve relevant information from a database of properties. This is where LangChain steps in to help organize the context of the conversation and keep track of the history, ensuring that the chatbot doesn’t lose sight of previous questions or answers. In essence, LangChain acts as the chatbot’s memory, allowing it to deliver a well-informed and relevant response.

Through this process, the customer gets the best possible answer based on their inquiry, whether it’s pricing, availability, or property details such as room count or square footage — all without the agent needing to lift a finger unless absolutely necessary.

In this way, the chatbot balances the efficiency of automation with the personalization that real estate inquiries often demand, all while lightening the load on the real estate agents themselves.

User Journey in the Chatbot

Let’s see what a typical conversation with the chatbot looks like. A user sends a message via WhatsApp:

User: “I’m looking for a 3-bedroom apartment in the city center.”

The chatbot quickly processes this message, classifies it as a property inquiry, and searches through its property database. It finds a few matching listings and responds:

Chatbot: “Here are three options:

1. 3-bed apartment, $200,000, located downtown.
2. 3-bed apartment, $250,000, near Central Park.
3. 3-bed apartment, $220,000, close to public transport.”

If the user needs more information, they can simply ask:

User: “Can I contact the agent for property number 2?”

The chatbot recognizes this as a request to speak with an agent. It notifies the agent by sending them a message with the client’s phone number and the property in question:

Message to Agent: “A client with phone number +123456789 is interested in property number 2.”

It then confirms to the user:

Chatbot: “The agent for property number 2 will contact you shortly!”

Throughout the conversation, the chatbot keeps track of what the user has asked, ensuring it provides relevant and consistent answers without losing context. Whether it’s providing property details or connecting users to an agent, the process is smooth and efficient, all while reducing the workload for agents.

Conclusion:

In this post, we’ve taken a high-level look at the real estate chatbot, exploring how it streamlines property inquiries and connects customers with agents through WhatsApp. We’ve covered the chatbot’s architecture, walked through a typical user interaction, and discussed how technologies like Twilio, Flask, and a RoBERTa-based classifier help create a seamless experience for both users and agents.

As mentioned earlier, this is the least technical post in the series, providing a solid overview of how the system works. In the upcoming posts, we’ll delve deeper into the technical aspects of the project, exploring Twilio's integration with WhatsApp, the use of BERT for intent classification, and LangChain's role in managing context and retrieving relevant property information.

Whether you’re a developer looking for technical insights or just curious about how chatbots like this are built, there’s much more to come!

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

How to Build a WhatsApp Real Estate Chatbot Using Twilio, Flask, and AI: Project Overview was originally published in FAUN — Developer Community 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

KEDA, short for Kubernetes Event-driven Autoscaling, allows us to scale applications based on events. It can be added to any Kubernetes cluster and works seamlessly with Horizontal Pod Autoscaling. Today, in this blog, we will explore HTTP request-based autoscaling with KEDA.

Why opt for autoscaling applications based on HTTP requests?

a) Consider a scenario where we have multiple applications running on Kubernetes that require substantial computing resources but are only needed for a few hours a day, such as during working hours in a development/QA environment. We could create a custom script to scale down the application using a cronjob to address this. However, this solution falls short when someone needs to work late at night or off-days. There are various cases that a cronjob can miss.

In such cases, scaling the application based on traffic becomes more desirable. If there is an incoming traffic to the application, it should automatically scale up, or else scale it down to zero.

b) There are several metrics available to be used to scale up/down the application like CPU usage, Memory usage, and several scaled object support offered by KEDA, but what if we would like to scale up the application based on the volume of traffic coming (HTTP request)?

Autoscaling with HTTP

The KEDA HTTP Add-on is designed to provide autoscaling capabilities for HTTP servers.
We can scale the application down to zero replicas and scale it up to the desired number of replicas. This helps reduce infrastructure costs, especially during weekends or off-hours when the Development/QA environments are less active than regular working hours. With this add-on, we can autoscale arbitrary HTTP servers based on the volume of incoming traffic, even down to zero replicas.

Understanding and installing the KEDA HTTP add-on

The KEDA HTTP Add-on is built on top of the KEDA core and utilizes an interceptor and external scaler to scale the target HTTP server. The components of the add-on include:

a) Operator: This operator listens/watches for a resource called HTTPscaledObject and creates and configures interceptors and scalers allowing your existing Deployment to autoscale based on incoming HTTP traffic.

b) External scaler: This component communicates scaling-related metrics to KEDA. The External scaler constantly pings the interceptor to get pending HTTP queue metrics. It transforms these data and sends them directly down to KEDA, which then makes a scaling decision.

c) Interceptor: It accepts the HTTP request, and forwards the HTTP requests to the target application. Sends the pending HTTP request queue metrics to an external scaler and holds requests in a temporary request queue when there isn’t any Pod ready to serve the traffic.

As you can see in the above image, the interceptor accepts the HTTP-based request, forwards them to the target application or holds them if the target application is scaled down to zero, and sends the pending HTTP request queue metrics to the external scaler. The external scaler gets the metrics data from the interceptor, transforms the data, and sends the data to KEDA, which makes scaling decisions.

The operator watches the HTTPScaledObject and configures the interceptor to forward the HTTP request to the target application.

Installation

Setting up KEDA and the KEDA HTTP add-on is a straightforward process. All you need is the Helm CLI to install the components.

helm repo add kedacore <https://kedacore.github.io/charts>
helm install keda kedacore/keda

helm install http-add-on kedacore/keda-add-ons-http

Once the installation is complete, you can start using the KEDA add-on by configuring your application and referencing it with HTTPScaledObject.

Installation with Devtron

For better visibility of the workloads, a dashboard always helps. Devtron comes with helm dashboard which can help you deploy any helm chart and observe the workloads from its user-intuitive dashboard. For more details about the helm dashboard by Devtron, feel free to check this blog.

We can install the Keda-add-ons-http from the Devtron’s chart store, we need to search for keda-add-ons-http and provide the basic installation configuration like application name, environment where it needs to be deployed and the project name.

Please refer to the screenshot for the inputs.

After we configure and deploy the helm chart, let’s wait for the deployment to complete. As you can see in the below image, Devtron automatically grouped all the workloads deployed with this helm chart and it shows the real-time application health details. It makes it much easier to debug and observe the application’s health with such dashboards.

Now we can start using the KEDA add-on for scaling the application based on the HTTP Metrics.

Note: HTTPScaledObject only works with deployment ( in the current version )

Understanding the HTTPScaledObject

The installation includes a new CRD (Custom resource definition) called [HTTPScaledObject.http.keda.sh](<http://HTTPScaledObject.http.keda.sh>) - HTTPScaledObject. The resources allows to autoscale HTTP-based application and sets up the required internal components to deploy HTTP application and expose it internally or externally.

When an HTTPScaledObject is created, it performs the following tasks:

• Update an internal routing table that maps incoming HTTP hostnames to internal applications.
• Furnish this routing table information to interceptors so that they can properly route requests.
• Create a ScaledObject for the Deployment specified in the HTTPScaledObject resource.

Once the HTTPScaledObject and its related resources are created by operator, requests can be sent through the interceptor to scale the application. These requests are sent to keda-add-ons-http-interceptor-proxy . The interceptor then forwards the requests to the target application based on the request's host.

Here is an example manifest for the HTTPScaledObject:

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
    name: xkcd
spec:
    hosts:
    - myhost.com
    scaleTargetRef:
        deployment: xkcd
        service: xkcd
        port: 8080
    replicas:
        min: 5
        max: 10
    scaledownPeriod: 300
    targetPendingRequests: 100

The Keda Add-on routes the application to the target application based on the host specified in the HTTPScaledObject manifest.

Deploying the Sample Application and Live Manifest of HTTPScaledObject

Here are the deployment and service manifests. You can use Devtron’s generic-helm-chart to deploy any kind of Kubernetes manifests, or you can simply use kubectl to deploy the change in your Kubernetes cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: scale-application-testing
  name: scale-application
spec:
  minReadySeconds: 60
  progressDeadlineSeconds: 600
  replicas: 1
  selector:
    matchLabels:
      app: scale-application-testing
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: scale-application-testing
    spec:
      containers:
          image: stefanprodan/podinfo
          imagePullPolicy: IfNotPresent
          name: scale-application
          ports:
            - containerPort: 9898
              name: app
              protocol: TCP
          resources:
            limits:
              cpu: 100m
              memory: 200Mi
            requests:
              cpu: 100m
              memory: 200Mi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: scale-application-testing
  name: scale-application
spec:
  ports:
    - name: app
      port: 80
      protocol: TCP
      targetPort: app
  selector:
    app: scale-application-testing
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: scale-application-service-proxy
spec:
  externalName: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local
  sessionAffinity: None
  type: ExternalName

Once the deployment and service are deployed, you can configure the HTTPScaledObject:

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
    name: scale-application
spec:
    hosts:
    - scale-application-service-proxy
    scaleTargetRef:
        deployment: scale-application
        service: scale-application
        port: 80
    replicas:
        min: 0
        max: 3
    scaledownPeriod: 300
    targetPendingRequests: 100

Upon creating the HTTPScaledObject, the target application is scaled down to 0 pods as no HTTP requests are passing through the interceptor proxy (keda-add-ons-http-interceptor-proxy). You can confirm this by running kubectl get pods.

We leverage the ExternalName service type to direct requests to the interceptor, which is keda-add-ons-http-interceptor-proxy. The request is routed through the service proxy, scale-application-service-proxy, and ultimately reaches the target application, scale-application.

To test this setup, you can use the following command:

curl -v <http://scale-application-service-proxy>

When you send a curl request to http://scale-application-service-proxy, the request goes through the interceptor, which then routes it to the correct application.

After making the request, you can check the status of the pods by running kubectl get pods. You should see that the pods have been created as expected.

Now in this current setup we can face a problem in upgrading the application when the current application is already scaled down due to no HTTP request. To resolve the problem statement we can trigger a job which will run post deployment of the application, the job will hit a curl request to the targeted application for scaling up the application after the deployment.

A sample manifest of the job is:

apiVersion: batch/v1
kind: Job
metadata:
   name: admin-service-curl
   annotations:
      helm.sh/hook: post-install, post-upgrade
spec:
   ttlSecondsAfterFinished: 100
   backoffLimit: 4
   template:
     spec:
       restartPolicy: Never
       containers:
        - name: curl-admin-service
          image: "@{{CURL_IMAGE}}"
          command:
            - /bin/sh
            - -c
            - curl -v <http://scale-application-service-proxy>

Conclusion

Scaling HTTP-based applications with KEDA and the HTTP Add-on brings significant benefits to Kubernetes environments. By dynamically adjusting the number of replicas based on incoming HTTP traffic, we can optimize resource utilization, improve application performance, and reduce costs.

Incorporating KEDA and the HTTP Add-on into your Kubernetes deployment not only enhances the scalability of your HTTP-based applications but also ensures efficient resource allocation. By scaling up or down based on real-time traffic demands, you can provide a seamless user experience while optimizing the utilization of your infrastructure.

KEDA and the HTTP Add-on empower developers and operators to achieve dynamic and efficient scaling of HTTP applications in Kubernetes, delivering enhanced performance, cost optimization, and a responsive user experience. Explore the potential of KEDA and leverage the HTTP Add-on to unlock the full scalability potential of your applications.

Not only with add-ons, but KEDA is also efficient enough to autoscale based on ALB metrics, based on Kafka Lag, Prometheus metrics and lots of other events and triggers.

Feel free join our community discord server and let us if you have any questions. We would be more than happy to help you.

Author:-Rupin Solanki

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

HTTP request-based autoscaling with Keda was originally published in FAUN — Developer Community 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

OneDev is a python aware self-hosted git server, with out of box CI/CD capability. It analyzes python code and CI/CD reports to make important information readily available to aid code navigation, comprehensation and review.

For python projects, it is able to:

1. Analyze code for symbol navigation and search
2. Display/search outline while view source code
3. Suggest CI/CD job templates
4. Show unit test, coverage and lint report, as well as statistics over time
5. Annotate source code with coverage and lint information

Let’s see how to get all of these with a real-world python project poetry.

Prepare the Environment

Firstable, run OneDev with below command:

docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v ./onedev:/opt/onedev -p 6610:6610 -p 6611:6611 1dev/server

Follow on screen instructions to set up the server, then select import from url like below:

Specify import url as https://github.com/python-poetry/poetry on next screen, and click import. Two projects will be created after a while like below:

Here project _python-poetry_ corresponds to organization _python-poetry_, and its child project _python-poetry/poetry_ contains imported repository. The hierarchical structure makes project management and setting inheritance a lot easier.

Code Analysis and Indexing

Now open project python-poetry/poetry to get into the repository page:

For just imported repository, a indexing in progress message will be shown to indicate that the source code is currently being analyzed and indexed. After that we can press ‘T’ to search symbols. For instance, type application to list all related definitions:

If we select the first entry, python file defining Application class will be shown:

Symbols can be highlighted and navigated in source view page. It also shows the code outline, which can be searched by pressing ‘O’.

CI/CD Support and Report Analysis

Now let’s add CI/CD jobs for this project. To do it, go back to repository root and click the link adding .onedev-buildspec.yml like below:

OneDev shows a GUI for CI/CD job setup, and the result will be saved into file .onedev-buildspec.yml in root of the repository. You may add job manually at this point, but OneDev will analyze your repository files and provide appropriate templates for you to start with:

For python, the template is created by inspecting files such as pyproject.toml, tox.ini, poetry.lock, setup.py, setup.cfg, or environment.yaml. Let’s use provided template and head on to job detail page:

You may edit steps and other settings as necessary here. For this project, we just save and commit without any change. The job will run automatically as it defines a trigger to fire upon commit:

Switch to running build of the job, wait a while, and it should be successful like below:

We can see from this page that the build version is detected from pyproject.toml, and also unit test and coverage report is published:

A ruff lint report will also be available if there are rule violations. To demonstrate, let’s edit file pyproject.toml to remove the line ignoring rule N818 in section tool.ruff.lint. Save and commit the file to trigger a new build, which will fail due to violations of rule N818. A ruff report tab is now available showing all violations:

We can click the line numbers to drill down violations in source view:

Besides violations, the source is also marked with code coverage info. When review code via pull request, these information will also be available in diff view if applicable.

Final Note

Besides Python, OneDev also supports Java, JavaScript, C/C++, C# and Golang. Support for more languages will be added in future versions. For details, please check https://github.com/theonedev/onedev.

Thanks for reading.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

OneDev — a Python Aware Git Server was originally published in FAUN — Developer Community 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the fast-evolving world of containerization, managing and distributing Docker images efficiently is crucial for both small teams and large enterprises. With a wide array of Docker image registry systems available, it can be overwhelming to decide which one best suits your needs. Whether you’re leveraging cloud-native solutions like AWS ECR, GCR, or Azure ACR, or seeking more control with open-source solutions like Harbor and Nexus, this guide will walk you through each registry’s key features, strengths, and use cases. By the end, you’ll have a clear understanding of how these registries compare and which one is right for your workflow.

1. Docker Hub

Docker Hub is the official and most widely used Docker image registry service. It allows users to store, manage, and distribute Docker images in both public and private repositories.

• Public and Private Repositories: Docker Hub allows users to create public repositories for sharing images with the world or private ones for internal use.
• Official Images: Docker Hub contains a large collection of “official images,” which are curated and maintained by Docker for various software, including operating systems and applications.
• Automated Builds: Docker Hub supports automated builds from GitHub or Bitbucket repositories, meaning you can link your code repositories and automatically trigger a build when new code is pushed.
• Content Trust: Docker Hub supports Docker Content Trust (DCT), which ensures that the images pulled from Docker Hub are signed and verified.
• Webhooks: Docker Hub allows setting up webhooks to notify when an image is pushed or updated in the repository, integrating it into CI/CD pipelines.
• Free Tier: Docker Hub offers a limited free tier with access to public repositories and limited private repository access. More features are available through paid plans.

2. Google Container Registry (GCR)

Google Container Registry (GCR) is a private Docker image registry offered by Google Cloud. It’s a fully managed service designed to store Docker images and is integrated with Google Cloud’s ecosystem.

• Integration with Google Cloud: GCR is tightly integrated with other Google Cloud services like Kubernetes Engine (GKE), Compute Engine, and Cloud Build.
• Regional Availability: GCR supports multi-region storage, allowing users to store images in locations closer to their infrastructure to reduce latency.
• IAM Integration: It uses Google Cloud’s Identity and Access Management (IAM) system for fine-grained access control and permissions for pulling or pushing images.
• Vulnerability Scanning: GCR offers image vulnerability scanning, helping you identify security issues in your container images.
• Private Networking: GCR can be configured to allow private access over Google’s Virtual Private Cloud (VPC), ensuring that traffic between Google Cloud resources and GCR never leaves Google’s network.
• Lifecycle Management: GCR supports lifecycle policies to automatically delete old or unused images based on your criteria.

3. Amazon Elastic Container Registry (ECR)

Amazon Elastic Container Registry (ECR) is a fully managed Docker container registry provided by AWS. It allows you to store, manage, and deploy Docker container images easily.

• AWS Integration: ECR is integrated with many AWS services, such as Elastic Kubernetes Service (EKS), Elastic Container Service (ECS), and AWS Lambda.
• Authentication and Access Control: ECR uses AWS IAM roles and policies to manage access control. It also supports Docker’s credential helper, allowing seamless authentication.
• Encryption: ECR encrypts images both at rest and in transit using AWS-managed or customer-managed encryption keys.
• Lifecycle Policies: ECR enables you to define lifecycle policies for managing the lifecycle of images, such as automatically removing untagged or older images.
• Image Scanning: It offers vulnerability scanning of images to identify common security issues.
• Cross-Region Replication: ECR supports cross-region replication, allowing you to replicate images to different AWS regions automatically.
• Pricing: You only pay for the storage used and data transferred when pulling images, making it a cost-effective solution.

4. Azure Container Registry (ACR)

Azure Container Registry (ACR) is a fully managed Docker registry service provided by Microsoft Azure. It integrates deeply with Azure’s cloud services and provides a scalable solution for storing Docker images.

• Azure Integration: ACR integrates seamlessly with Azure Kubernetes Service (AKS), Azure App Service, and other Azure services.
• Access Control with Azure AD: It supports Azure Active Directory (AD) authentication for managing who can access or push images to the registry.
• Geo-Replication: ACR offers geo-replication, which enables users to replicate images across multiple Azure regions, improving availability and reducing latency for global deployments.
• Task Automation: ACR Tasks allows you to automate tasks such as image builds, tests, and deployments, providing continuous integration/continuous deployment (CI/CD) capabilities.
• Content Trust: ACR supports Docker Content Trust (DCT) for verifying the integrity of your images by ensuring that only signed images can be pulled.
• Image Scanning: ACR integrates with Microsoft Defender for Cloud to provide vulnerability scanning for your container images.
• Dedicated Tiers: ACR offers different pricing tiers (Basic, Standard, Premium) to accommodate various storage and performance requirements.

5. Harbor

Harbor is an open-source container image registry that provides additional security, image management, and governance features on top of the standard Docker Registry.

• Role-Based Access Control (RBAC): Harbor offers fine-grained role-based access control (RBAC) for managing user permissions at both the project and image level.
• Vulnerability Scanning: Harbor integrates with the Clair or Trivy vulnerability scanning tools to identify and report security vulnerabilities in your images.
• Content Trust: It supports image signing and verification using Notary, ensuring that only signed images are pulled from the registry.
• Image Replication: Harbor allows users to replicate images across multiple Harbor instances, supporting scenarios where you need to distribute images globally or across multiple data centers.
• Audit Logs: Harbor provides detailed audit logs that track user actions, such as pushing or pulling images, improving security and traceability.
• Helm Chart Repository: Harbor can also serve as a repository for Helm charts, a feature that helps users manage Kubernetes application packages.
• Garbage Collection: Harbor has a garbage collection feature that helps clean up unreferenced image layers, freeing up storage space.
• Custom Security Policies: Harbor allows setting custom policies for image management, such as preventing the use of vulnerable images or enforcing certain image labels.

6. Quay

Quay is a container registry that focuses on security, providing features like vulnerability scanning, image mirroring, and detailed auditing. It is offered by Red Hat and integrates well with Kubernetes and OpenShift.

• Vulnerability Scanning: Quay provides built-in vulnerability scanning through the Clair tool, identifying security issues in container images.
• Repository Mirroring: Quay supports repository mirroring, which allows users to mirror external repositories for faster pulls or ensure availability.
• Fine-Grained Permissions: Quay allows detailed control over who can access, push, or pull images, supporting both public and private repositories.
• Built-In Logging and Auditing: Quay offers extensive audit logs and logging functionality for tracking all actions related to image management.
• OpenShift Integration: As a Red Hat product, Quay integrates seamlessly with OpenShift, a Kubernetes-based platform for deploying and managing containers.
• Multiple Storage Backends: Quay supports multiple storage backends, including S3, GCS, Azure Blob Storage, and more, providing flexibility for different infrastructures.
• Multi-Architecture Support: Quay supports multi-architecture images, enabling users to build and push images for different CPU architectures like x86_64 and ARM.

7. GitLab Container Registry

GitLab offers a built-in Docker registry as part of its DevOps platform, allowing you to manage container images alongside your code and CI/CD pipelines.

• Tight Integration with GitLab CI/CD: The GitLab Container Registry is tightly integrated with GitLab’s CI/CD pipelines, allowing you to build, test, and push Docker images directly from your CI jobs.
• Private by Default: All repositories in GitLab are private by default, ensuring that your images are secure and only accessible to authorized users.
• Project-Level Registry: Each GitLab project has its own Docker registry, simplifying the management of images specific to that project.
• Access Control: GitLab uses its built-in access control system to manage permissions for the registry, meaning you can use GitLab’s user and group permissions to control access to your images.
• Dependency Scanning: GitLab’s security features include dependency scanning, which can identify vulnerabilities in the images stored in your registry.
• Multi-Cloud Support: While GitLab itself can be hosted on-premise or in the cloud, its container registry works with cloud providers like AWS, GCP, and Azure.

8. JFrog Artifactory

JFrog Artifactory is a universal repository manager that supports Docker images and many other types of binaries. It’s a highly scalable and enterprise-grade registry solution.

• Universal Repository: Artifactory supports not just Docker images but also other artifact types like Maven, npm, and NuGet, making it a comprehensive solution for artifact management.
• High Availability (HA): Artifactory offers HA setups for enterprises that need to ensure maximum uptime and reliability for their container registry.
• Image Promotion: Artifactory provides the ability to promote images from one repository to another, which is useful in CI/CD pipelines (e.g., promoting an image from a development to a production repository).
• Access Control: Artifactory uses its own permission model to provide detailed access control to repositories and images, supporting LDAP and SSO integrations for user management.
• Vulnerability Scanning: Artifactory integrates with JFrog Xray to provide vulnerability scanning and license compliance checks for images stored in the registry.
• Replication: Artifactory supports multi-site replication, which allows images to be synchronized between multiple data centers for faster access and disaster recovery.

9. Nexus Repository

Nexus Repository, developed by Sonatype, is a universal repository manager that supports a wide range of artifact formats, including Docker images. It provides a comprehensive solution for managing binaries and containers in a single location.

• Universal Repository: Nexus Repository supports multiple package formats like Docker, Maven, npm, NuGet, Python (PyPi), RubyGems, and more, allowing you to store all artifacts in one place.
• Docker Registry: Nexus can serve as a private Docker registry, offering support for both hosted and proxy repositories. You can proxy Docker Hub or other remote Docker registries to cache images locally.
• Fine-Grained Access Control: Nexus provides role-based access control (RBAC), allowing you to define permissions for users and groups to access certain repositories or actions (e.g., pushing or pulling images).
• Security and Vulnerability Scanning: Nexus integrates with Sonatype’s Nexus Lifecycle and Nexus Firewall to provide vulnerability scanning and ensure that insecure components are blocked before entering your registry.
• Repository Health Checks: Nexus can perform health checks on repositories to monitor for issues like corrupted files or vulnerabilities.
• Caching and Proxying: Nexus can act as a proxy repository for other Docker registries, caching images locally to reduce bandwidth usage and improve retrieval speeds.
• Cloud and On-Prem Support: Nexus can be hosted either on-premises or in the cloud, providing flexibility depending on your infrastructure needs.
• Storage Backend: Nexus supports several storage backends, including local storage and cloud storage services like AWS S3 and Azure Blob Storage.

10. Self-hosted Docker Registry

The Docker open-source registry is a simple self-hosted solution for storing and distributing Docker images. This registry is part of the official Docker project and can be deployed on your own infrastructure for complete control over your Docker images.

• Lightweight: Docker Registry is a lightweight, minimalistic solution for hosting Docker images. It can be run on any server that supports Docker.
• Private and Secure: You can set up your own private Docker registry with SSL/TLS encryption and Basic HTTP Authentication for access control.
• Storage Options: The self-hosted registry supports various storage backends such as the local filesystem, AWS S3, Google Cloud Storage, Azure Blob Storage, and more.
• Content Trust: Docker Registry supports Docker Content Trust (DCT), ensuring that images pulled from the registry are signed and verified for authenticity.
• Garbage Collection: It provides garbage collection to clean up unreferenced or unused image layers, helping to optimize storage usage.
• Customizable: Since it’s open-source, you can customize and extend Docker Registry to meet specific requirements, such as integrating with CI/CD pipelines, adding custom authentication, or improving logging.

Feature Comparison

Conclusion

Choosing the right Docker registry depends on your infrastructure, security requirements, and integration needs. Here’s a quick guide to help you choose:

• For public image sharing: Docker Hub is the go-to option for public repositories, especially with its wide reach and official image support.
• For Google Cloud users: Google Container Registry (GCR) offers deep integration with Google Cloud services and advanced features like vulnerability scanning and IAM-based access control.
• For AWS users: Amazon ECR integrates seamlessly with AWS services, offering fine-grained IAM policies and automatic encryption.
• For Microsoft Azure users: Azure Container Registry (ACR) provides native integration with Azure services and features like geo-replication and image scanning.
• For enterprise or on-premise use: Harbor, Quay, JFrog Artifactory, and Nexus Repository provide more comprehensive features for security, vulnerability scanning, replication, and RBAC.
• For self-hosted solutions: The open-source Docker Registry is a good choice for teams that want full control over their registry without relying on a cloud provider or third-party vendor.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Comparative features of Docker Container Registries was originally published in FAUN — Developer Community 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.