Architecture overview
This page describes Aidin’s architecture at the level relevant to customers: how tenants are isolated, how identity works, and which open-source projects the platform builds on. Internal operations detail is deliberately not published here (see Operations).
Multi-tenancy
Section titled “Multi-tenancy”Aidin is a multi-tenant platform. Each account’s workloads run in a dedicated project namespace with:
- Role-based access control — namespace administration rights are granted only to the namespace owner.
- Network isolation — platform-enforced network policies and an authorization layer sit between tenants and in front of public entry points.
- Per-namespace quota — CPU, memory, storage, and GPU ceilings bound each project (see Storage and quotas).
Identity
Section titled “Identity”- Users authenticate through the Aidin identity service (single sign-on at
login.aidin-ai.com). - The platform derives user identity from verified claims in the session, injected server-side into service requests. Client-supplied identity fields are ignored.
- Workspaces, pipelines, and serving all run under this identity — no separate per-service accounts for customers.
Public entry points
Section titled “Public entry points”| Host | Purpose |
|---|---|
aidin-ai.ir |
Product site |
login.aidin-ai.com |
Identity / sign-in |
platform.aidin-ai.com |
Platform dashboard and workspace services |
docs.aidin-ai.ir |
This documentation |
Upstream projects
Section titled “Upstream projects”Aidin runs managed, version-pinned deployments of open-source components — principally Kubeflow (notebook controller, pipelines), KServe (inference), Katib (hyperparameter search), and Kubernetes itself — combined with Aidin’s own dashboard, lifecycle, billing, and identity services. The exact deployed versions are listed in Integrations and deployed versions; those pins govern this documentation set.
What is not published
Section titled “What is not published”Internal architecture and operations documentation — cluster topology, privileged procedures, credentials handling, security-sensitive runbooks — stays in restricted internal documentation. Public customers do not need it, and publishing it would reduce platform security. See Operations for what is public.