Platform architecture

This page describes the verified architecture of the Aidin platform at the level relevant to customers, measured against the deployed platform and authoritative source in the 2026-11-10 release-candidate review. Statements that could not be verified are explicitly marked. Aidin-specific behavior always takes precedence over upstream Kubeflow defaults.

Privileged operational detail — node topology, cluster internals, admission object names, exact internal quotas — is deliberately not published here; see Operations.

Platform overview

Aidin runs a managed MLOps platform on Kubernetes, serving both managed Aidin Academy deployments and the public Aidin Cloud on shared infrastructure with strict isolation between them. Public tenants are untrusted by default: nothing relies on user-interface restrictions alone, and every entitlement, quota, and ownership rule is enforced server-side at the admission boundary.

Public entry points (verified):

Host	Role
aidin-ai.ir	Product site
login.aidin-ai.com	Identity service (single sign-on)
platform.aidin-ai.com	Dashboard, notebooks, pipelines, registry, endpoints
harbor.aidin-ai.com	Managed container registry
support.aidin-ai.com	Support portal

All public traffic enters through a single managed ingress; each running notebook gets its own platform route that exists only while the notebook runs.

Trust and identity model (verified)

• Your identity is established by the identity service and injected server-side into service requests; client-supplied identity headers are stripped at the edge and cannot be forged from a browser or script.
• Ownership of projects, notebooks, and models is derived from that verified identity, never from request fields.
• Per-notebook and endpoint routes are governed by platform authorization rules so a tenant can only expose routes to its own workloads.

Multi-tenancy and enforcement (verified)

Each project runs in its own namespace with role-based access control, network isolation, and quotas. Server-side admission enforces, among other rules:

• CPU/memory request ceilings per workload and GPU maximums where GPU is entitled;
• GPU requests are denied outright for namespaces without a GPU entitlement;
• notebooks must be workspace-backed (persistent volume mounted at /home/jovyan);
• notebook workloads never schedule onto platform control-plane nodes;
• per-namespace GPU fair-share caps backstop the entitlement gate.

Scheduling and compute flow (verified)

1. A workload (notebook, pipeline step, training job) requests CPU/memory/GPU within your project quota.
2. The platform’s queue-aware scheduler (Kueue-based fair-share queues) admits it — workloads wait in queue rather than failing when capacity is busy.
3. While a workload runs, its quota is reserved; stopping releases the reservation immediately and restarting re-acquires it (verified stop → start cycle).

GPU access additionally requires an account entitlement and is currently restricted at public launch — see Compute profiles.

Storage architecture (verified)

• Workspace volumes are managed replicated block storage (Longhorn; ReadWriteOnce, replicated ×2 across storage nodes).
• A notebook workspace is a persistent volume claim named after the notebook (default 5Gi), mounted at /home/jovyan.
• Volumes have no owner references by design: they survive notebook deletion and remain in your workspace until removed.
• No backup target is configured — replicas cover hardware loss but not deletion or corruption; keep independent copies of critical data (Workspace storage).

Component map (verified deployed stack)

Plane	Components
Notebooks	Kubeflow notebook controller (v1.9.0) + Aidin notebook lifecycle service, Jupyter web app
Tenancy	Profile controller (v1.9.0), Aidin pull-secret propagation
Pipelines	Kubeflow Pipelines 2.14.3 (API, UI, Argo workflow engine, metadata + artifact stores)
Serving / training / AutoML	KServe 0.20 (+ models web app, Knative), training operator, Katib 0.17
Dashboards	Aidin central dashboard, TensorBoard/volume web apps
Platform services	Gateway and inference authorization, model publication, billing, identity (Authentik/Dex/oauth2-proxy)
Infrastructure	Kueue scheduler, Longhorn storage, Harbor registry, monitoring stack

Versions are pinned per Integrations and deployed versions and govern this documentation set.

Verified-status legend

Marker	Meaning
(verified)	Observed on the deployed platform or in authoritative source during the 2026-11-10 release-candidate review
pending verification	Not verified at publication time; do not rely on it

Evidence for verified claims is recorded in the release-candidate evidence directory (internal; not published).