> For the complete documentation index, see [llms.txt](https://docs.nfh.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nfh.global/product-documentation/products/discovr/deploying-your-own-discover.md).

# 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**](https://github.com/beckn/beckn-discovr/blob/main/discovr-deployment/DEPLOYMENT.md)

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](https://github.com/beckn/beckn-discovr/blob/main/discovr-deployment/DEPLOYMENT.md#1-architecture) 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](#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](https://github.com/beckn/beckn-discovr) 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](https://github.com/beckn/beckn-discovr/blob/main/discovr-deployment/DEPLOYMENT.md) 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:

   ```json
   {
     "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](/build/creating-a-network/catalog-publishing-and-discovery.md#step-4-point-your-registry-record-at-the-index) for the full walkthrough.
5. **On a VM:** create the shared Docker network, pull images, and bring the stack up:

   ```bash
   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](#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](https://github.com/beckn/beckn-discovr/blob/main/discovr-deployment/DEPLOYMENT.md#7-first-time-setup) 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](https://github.com/beckn/beckn-discovr/blob/main/discovr-deployment/DEPLOYMENT.md#8-troubleshooting) and [Rollback](https://github.com/beckn/beckn-discovr/blob/main/discovr-deployment/DEPLOYMENT.md#9-rollback) sections.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.nfh.global/product-documentation/products/discovr/deploying-your-own-discover.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.