Skip to main content

What is DT Edge Platform?

The 5-minute big picture. Read this once; everything else fits on top.

In one sentence​

DT Edge Platform is a license-gated, multi-tenant Kubernetes-cluster fleet management platform. You add clusters by uploading kubeconfigs (or by provisioning new ones via the bundled Provisioner), and DT Edge Platform surfaces a marketplace + helm release manager + observability + VM workflows on top.

The four things DT Edge Platform does​

1. Holds a fleet of clusters​

You register Kubernetes clusters as edge instances. DT Edge Platform stores their kubeconfigs encrypted, probes them periodically for health, surfaces them as install targets in the marketplace flow. "Fleet" can mean two clusters or two thousand — the model is the same.

2. Curates an app catalog (marketplace)​

A marketplace of helm chart packages, with optional typed install forms (no more hand-editing values.yaml for the common case). Org admins publish packages from their registries; org users install with a few clicks.

3. Operates and observes those apps​

Every install lands as a helm release DT Edge Platform knows about. You can upgrade, rollback, view rendered resources, edit YAML, watch metrics + logs scoped to the release, and tie it to alarm rules — all from the same surface.

4. Multi-tenant the whole thing​

Every owned row has an org_id. Every API call has an org filter. Org members see their own org's data; super-admins can manage cross-org. Or the deployment runs in single-tenancy — one org auto-bootstrapped, admin/public pages hidden — and the rest of the product is identical.

What DT Edge Platform is NOT​

  • A k8s control plane. Your edge clusters run their own kubelets and apiservers. DT Edge Platform talks to them via stored kubeconfigs; if they go offline, DT Edge Platform notices and reports it but can't bring them back.
  • A monitoring stack itself. DT Edge Platform integrates with Grafana
    • Prometheus + OpenSearch (you bring or run those). The metrics
    • logs + alarms surfaces are query layers, not data stores.
  • A CI system. Promotion / staging / approval flows live outside DT Edge Platform. The marketplace tells you what's installable; it doesn't enforce a release pipeline.
  • An infra provisioner of its own. When you want to provision new VMs into a k3s cluster, DT Edge Platform calls the upstream Provisioner service (separate codebase). Without Provisioner configured, DT Edge Platform still works — it just can't spawn new clusters from VMs.

The four moving parts​

browser → UI → API → DB + Redis
              ↓     ↘
         worker     scheduler
              ↓
        edge clusters (helm SDK + kubectl)
        Provisioner (REST)
        Grafana / Prometheus / OpenSearch
  • API — the HTTP surface. Authenticates, runs casbin RBAC, serves reads, queues async work
  • Worker — runs the helm installs / upgrades / VM actions asynchronously. Streams progress over WebSocket.
  • Scheduler — singleton, leader-elected, fires periodic enqueues (fleet capacity aggregation, edge health checks, release sync)
  • UI — the Next.js app you're looking at

Where DT Edge Platform sits in the bigger picture​

[ customer ] → dtedge (this product)
                   ↓ kubeconfigs
              [ N edge clusters running k3s + KPS + opensearch + ... ]
                   ↑ remote-write
              [ central Grafana + Prometheus + OpenSearch ]

[ operator ] → dtedge-license-issue (separate, internal-only)
                   ↓ signs
               [ JWT licenses ] → dtedge

(when configured)
[ dtedge ] ↔ Provisioner ↔ VM nodes (SSH + Ansible) → new k3s clusters

Three repos, one product family:

  • dtedge-backend + dtedge-ui — what you log into
  • dtedge-license-issue — the operator's offline JWT signer
  • provisioner — the optional cluster-from-VMs service

The license is the contract​

A signed JWT, fingerprint-bound to your install, declaring:

  • Tenancy — single or multi (the deployment shape)
  • Limits — per-org count caps + fleet capacity caps
  • Public resources — whether super-admin sees Public Edges / Global Marketplace etc.
  • Expiry + grace — how long before the API switches to read-only

The license is required — no license, no API. See License states.

Why you're here​

If you logged in and you see this docs site, you're using a running install. The question to start with is which of these matches your role:

  • App developer in an org → install / upgrade / monitor your apps; alarms when something breaks
  • Operator / SRE of an org → all of the above + alarms management + runbooks
  • Org admin → all of the above + members, roles, registries, marketplace publishing
  • Super-admin → all of the above + license + system settings
    • cross-org admin pages

See also​

  • Tenancy — the most important architectural axis
  • License states
  • Backend docs: Overview — much deeper if you're building, not using