open platform

The missing layer between Kubernetes and real project evolution.

Kubernetes orchestrates containers. Other tools describe applications. YAS lets you evolve a project's infrastructure declaratively.

It is an open-source, Kubernetes-native application platform designed to deploy and operate APIs, web applications, cron jobs, and databases across multiple isolation and compliance profiles, with a one-click GitOps-driven development experience. It provides a GitOps workflow on Kubernetes, without sacrificing control, portability, or extensibility.

From shared to network isolation and compliance, everything is controlled from a single declarative source.

Open source. Extensible. Built to grow.

project.yaml
project: acme-store
deploymentMode: network-ovn
services:
  api:
    source: git@github.com:acme/store-api
    type: api
    env: prod
  web:
    source: git@github.com:acme/store-web
    type: static
    env: prod
  jobs:
    nightly-sync:
      type: cronjob
      schedule: '0 2 * * *'
databases:
  main:
    engine: postgres
    backups: enabled
    pitr: enabled
Managed services

Components with resources, high availability, and defined operations

Each service type exposes clear parameters: replicas, HA, backups, and limits. The goal is for teams to choose criticality without reinventing operations.

Web

Frontend / Static

HTTP service with edge caching and atomic deployments.

  • Replicas: 2-4 (HA)
  • Autoscaling by CPU / RPS
API

Backend

Business services with network policies and resource limits.

  • Replicas: 2-6 (HA)
  • Defined requests/limits
  • Ingress mTLS / auth
Cron / Jobs

Scheduled tasks

Jobs with concurrency control and retries.

  • Limited concurrency
  • Retries and backoff
  • Failure alerts
DB

Managed PostgreSQL

Managed cluster with backups and replication.

  • HA: 3 replicas (1 primary + 2 standby)
  • Daily backups + PITR
Deployment modes

Four deployment modes: cost, isolation, and security as project properties

YAS standardizes how projects run without forcing a single model. Isolation level is a single choice, not a re-architecture.

Shared
Shared Runtime

Multiple projects share cluster base services. Ideal for dev/staging at low cost.

  • No dedicated namespace (convention or shared namespace)
  • Basic RBAC and limits
  • Fast provisioning and deploys
Namespace
Namespace Isolation

Logical isolation per project with quotas, RBAC, and policies. Balanced for multi-team environments.

  • Dedicated namespace per project
  • ResourceQuotas / LimitRanges
  • Policy profiles (OPA/Kyverno/PSA)
Network (OVN)
Network Isolation (Kube-OVN)

Network isolation between projects with default-deny and ingress/egress control.

  • Per-project network segmentation
  • Default-deny NetworkPolicies + allowlists
  • Fit for multi-tenant workloads with sensitive data
Compliance
Compliance-Ready (roadmap)

Profile designed for audit and certification requirements. Built for hardening and traceable evidence.

  • Supply-chain (SBOM/provenance) and image control
  • Audit logging and retention
  • Strict policies and hardening (CIS/PSA)
How it works

A layer on top of Kubernetes, built with cloud-native components

YAS does not replace Kubernetes: it turns it into a projects API. From a single manifest, it creates pipelines, runtime resources, databases, and infrastructure, applying the chosen isolation profile.

Builds and automation

Tekton pipelines run build, test, push, and triggers on code changes.

Reproducible pipelines - Registry integration - GitOps strategies

Declarative infra

Provision dependencies with Crossplane (DNS, buckets, queues, etc.) through a consistent API.

Multi-cloud / on-prem - Reusable compositions - Platform/app separation

Operated PostgreSQL

Managed PostgreSQL with CloudNativePG: backups and PITR built in.

Scheduled backups - PITR (WAL) - Kubernetes-native operations

GitOps-first

Designed for Argo CD/Flux: traceable changes, environment promotion, and clear rollbacks.

Git audit - Controlled promotion - Predictable rollbacks

Network isolation

Kube-OVN mode for per-project segmentation and ingress/egress control.

Default-deny - Per-service allowlists - Serious multi-tenant

Policies and security

Profiles apply limits, RBAC, and policies at each level without rewriting manifests.

Per-project profiles - PSA/OPA/Kyverno - Compliance roadmap

Roadmap

Phased deliveries focused on validation and real adoption

We prioritize early value: product validation and the Project contract first, then integrations and advanced isolation modes.

Current 2026 - Q1
Phase 0 · 2025
Validation bootstrap

Product validation with pilot teams and the base YAML definition.

Phase 1 · 2026 Current
API/CRD Project + status + basic modes

Stable API for Project, states, and shared/namespace modes as the operational base.

Q1
Phase 2 ·
Tekton integration (builds), Argo CD templates

Build pipelines and GitOps templates for continuous delivery.

Phase 3 ·
Kube-OVN isolation mode

Network isolation with default-deny policies and ingress/egress control.

Phase 4 ·
Compliance-ready profile

Hardening, audit evidence, and controls for regulated environments.