Builds und die Ausführungsumgebung

Wenn Ihr Agent auf nyxory ausrollt, laufen seine Befehle nicht auf Ihrem Laptop. Sie laufen auch nicht „im Cluster“ mit Cluster-Zugangsdaten. Sie laufen in einer Ausführungsumgebung je Projekt, die wir für Sie betreiben. Diese Seite erklärt diese Umgebung, denn mit keinem Teil der Plattform hat Ihr Agent mehr zu tun.

Delegation statt Zugangsdaten

Klassische Remote-Ausführung gibt dem Aufrufer Zugangsdaten in die Hand, etwa einen SSH-Schlüssel, eine kubeconfig oder ein Cloud-Token. Das Sicherheitsmodell schrumpft dann auf „die Zugangsdaten schützen“.

nyxory dreht das um. Ihr Agent hat genau eine Sache in der Hand, ein nyx_-Token. Er sieht nie eine kubeconfig, nie Cloud-Zugangsdaten, nie den Cluster. Ein Tool-Aufruf drückt eine Absicht aus („führe diesen Befehl in diesem Projekt aus“). Die Plattform authentifiziert den Aufruf, prüft, ob Ihnen das Projekt gehört, und führt erst dann die privilegierte Aktion aus, in der isolierten Umgebung Ihres Projekts und nirgends sonst. Jedes Projekt ist ein eigener Namespace mit eigenem Service Account, eigenen Network Policies und eigenem Ressourcenkontingent.

Dieses Delegationsmodell ist der Kern der Architektur von nyxory, eine hybride Ausführungsumgebung für Agenten. Der Agent drückt die Absicht aus, die Plattform führt die privilegierte Aktion aus. Für die Architektur ist ein Patent angemeldet.

Das Arbeitsverzeichnis

Jedes Projekt hat ein dauerhaftes /workspace, in dem die Deploy-Arbeit passiert:

• nyx_shell führt dort Befehle aus, etwa um Ihr Repo zu klonen, package.json anzusehen oder ein tsc --noEmit laufen zu lassen, bevor ein vollständiger Build Geld kostet.
• nyx_read_file / nyx_write_file / nyx_edit_file geben Ihrem Agenten gezielten Dateizugriff, etwa um Konfigurationen zu lesen oder Kubernetes-Manifeste zu schreiben. Der Quellcode Ihres Repos ist für die Plattform schreibgeschützt. Schreibzugriffe im geklonten Repo werden blockiert. Der Agent kann also Manifeste und Build-Artefakte korrigieren, schreibt aber nie unbemerkt Code um, den Sie verfasst haben.
• nyx_set_secret speichert Secrets schon beim Schreiben verschlüsselt. Ihre Apps bekommen sie als Umgebungsvariablen. Einen gespeicherten Wert zeigt das Tool nie wieder an. Im eigenen Projekt kann der Agent sie lesen, in keinem anderen.

Builds laufen separat

nyx_build_and_push_image baut Ihren Container auf unserer Infrastruktur, nicht auf Ihrem Rechner und nicht in Ihrem Arbeitsverzeichnis. Jeder Build läuft in einer eigenen, isolierten Build-Umgebung, die nur diesem Zweck dient. Sie hat keinen Zugriff auf andere Mandanten, auf Interna des Clusters oder auf Zugangsdaten der Plattform. Danach pusht der Build in unsere Registry und gibt eine image_ref zurück, die Ihr Agent in das Deployment-Manifest einträgt.

Es gibt zwei Builder:

• Buildpacks (cnb, der Standard) brauchen keine Konfiguration. Der Build erkennt Ihren Stack (Node, Python, Go, …) und erzeugt ein Image ohne Dockerfile.
• dockerfile kommt zum Einsatz, wenn Ihr Repo ein echtes Dockerfile mitbringt. Unterpfade in Monorepos gehen über ein Argument für den Build-Kontext.

Die Tags werden aus Ihrem Git-SHA abgeleitet. Es gibt kein latest, und Rollbacks sind vollständig reproduzierbar.

Deploys sind explizit

Nichts wird nebenbei ausgerollt. nyx_deploy_manifests wendet in Ihrem Projekt genau die Manifeste an, die Ihr Agent geschrieben hat. Sie können Ihren Agenten jederzeit bitten, sie vorher zu zeigen, und Sie können sie jederzeit exportieren. Rollout-Status, Verlauf und Logs liefern nyx_app_get (view: deployments für den Verlauf) und nyx_app_logs.

Private Repos funktionieren einfach

Öffentliche Repos werden direkt ins Arbeitsverzeichnis geklont. Private GitHub-Repos laufen über die GitHub App von nyxory. Sie installieren sie einmal im Browser. Danach nutzt jeder Klon, auch der Klon in einem isolierten Build, kurzlebige Tokens, die für jeden Vorgang neu ausgestellt werden. Keine Deploy Keys, keine PATs, nichts zu rotieren. Siehe Aus einem privaten Repo ausrollen.

Nächste Schritte

• So funktioniert nyxory, der Aufruf von nyx_brain und der vollständige Deploy-Ablauf
• Next.js-App ausrollen, der Ablauf von Anfang bis Ende
• Projekte und Konten, wie die Obergrenzen für RAM und CPU bestimmen, was der Agent ausrollen kann