Deploying your own Discover

How to deploy your own instance of the Beckn Discovr service, and what you need to have ready before you start.

You can stand up your own instance of the Discovr catalog discovery service — fronted by the Onix adapter — either as a self-hosted stack on a single VM, or on a Kubernetes cluster. Both run the same set of containers, using public Docker Hub images. No cloud vendor lock-in and no image registry authentication required.

The full architecture, every container, every configuration setting, and step-by-step setup instructions for the VM (docker-compose) path are maintained here:

Beckn Discovr — Deployment & Configuration Reference

This page summarizes what to prepare before you start and how the pieces fit together. For anything not covered here — service-by-service config, proxy setup, troubleshooting, rollback — follow the linked guide, which is the source of truth.

Architecture overview

The stack is the same set of services whether it runs as docker-compose on a VM or as workloads on a Kubernetes cluster:

• onix-discover — the only public-facing container. A Beckn protocol gateway (signature verification, schema validation, signing, routing) sitting in front of everything else.
• catalog-discover-job — runs discover queries and publishes results to Kafka.
• catalog-publish — receives catalog/push / catalog/on_pull, indexes into Elasticsearch and Postgres.
• response-dispatcher — consumes query results from Kafka and delivers on_discover callbacks back to the requesting BAP via onix-discover.
• Infra services (internal-only) — Postgres+PostGIS, Elasticsearch, Kafka, Redis.
• Ingress — a single public entry point in front of onix-discover (Nginx Proxy Manager on a VM; an ingress controller/load balancer on Kubernetes).

See the linked guide's architecture section for the full request-flow diagram and image list.

Prerequisites

Have these ready before you start, regardless of deployment target:

Item	Where it comes from
A registered subscriber identity on DeDi (subscriberId, e.g. discover.example.com)	Your network's DeDi registry
An Ed25519 signing keypair and an X25519 encryption keypair, base64-encoded	Generated and registered against the subscriberId above
A DeDi key ID for that keyset	Assigned when you register the keys
A public base URL for this deployment (DNS name or IP-based)	Your domain / VM's public IP
A strong Postgres password (don't use the sample default)	—
Outbound internet access (to pull images and fetch the Beckn API schema at startup)	—

No cloud registry auth is needed — all application images pull anonymously from the fidedocker org on Docker Hub.

If deploying on a VM

• Docker and docker compose installed on the VM.

If deploying on Kubernetes

• A Kubernetes cluster sized as in Cluster sizing below.
• SSD-class and standard-class storage classes available on the cluster.
• An object storage bucket for backups, plus a credential the backup jobs use to write to it.

Cluster sizing

If deploying on Kubernetes, the full Discovr stack (services, database, search, event bus, and backups) needs approximately the resources below to start.

Minimum resources [Non-Production]

Resource	Starting size
CPU	~12 vCPU
Memory	~20 GiB

Recommended node pool

Environment	Node pool	Total capacity
Non-production	3 nodes × 4 vCPU / 16 GiB	12 vCPU / 48 GiB
Production	2 nodes × 8 vCPU / 32 GiB (recommended)	16 vCPU / 64 GiB

Start with the non-production sizing and scale up — add nodes or enable autoscaling — as catalogue size and query load grow. Disk storage also grows with the catalogue over time.

Deploying

At a high level:

1. Register your subscriber identity, keys, and key ID in DeDi (see Prerequisites above).
2. Clone the beckn-discovr repository and fill in your real subscriberId, keys, passwords, and public URI into discovr-stack.yml and onix-discover/discover-adapter.yaml.
3. Set plugins.crawler.config.networks in discover-adapter.yaml to the network ID(s) you want this deployment to crawl, e.g. networks: "nfh.global/testnet". Without this, the crawler plugin runs but has no networks to discover peers on, so it never finds any catalogs. See the "Catalog crawler" section of the linked guide for the full config reference.
4. The crawler only finds peers whose own DeDi Subscriber record has a non-empty meta.catalog_index_urls — this is set on each provider's own record, not on anything in this deployment, but it's worth confirming for any peer you expect this deployment to discover:

   {
     "subscriber_id": "bpp.freshmart.local-retail.net",
     "type": "BPP",
     "url": "https://bpp.freshmart.local-retail.net/beckn/",
     "meta": {
       "catalog_index_urls": [
         { "url": "https://cdn.freshmart.example/beckn/index/becknCatalogs.index.json" }
       ]
     }
   }

   See Linking your catalog index for discovery for the full walkthrough.
5. On a VM: create the shared Docker network, pull images, and bring the stack up:

   docker network create beckn-network
   docker compose -f discovr-stack.yml pull
   docker compose -f discovr-stack.yml up -d

   On Kubernetes: translate the same services/config into your cluster's manifests (Deployments, Services, ConfigMaps/Secrets for the values above), sized per Cluster sizing.
6. Configure your ingress (Nginx Proxy Manager on a VM; an ingress/load balancer on Kubernetes) with the /beckn/* routing rules and an SSL certificate for your domain.
7. Restrict network access to only the ports/paths that need to be public.

Follow the First-time setup section of the linked guide for the exact commands, proxy-host configuration, and rewrite rules for the VM path — they're not duplicated here to avoid drift as the stack evolves.

Troubleshooting and rollback

Common startup issues (schema-fetch timeouts, crawler module errors, signature verification failures) and the rollback procedure are documented in the linked guide's Troubleshooting and Rollback sections.