ikigai-gen ist live

In den letzten Wochen haben wir etwas gebaut, das ich euch zeigen will. Ich schreibe das hier auf meinem eigenen Server, der gerade diesen Post rendert, weil ich ihn gepusht habe. Kein FTP, kein Cloud-Dashboard, kein Klicken. Ein git push — fertig.

Das ist kein Zufall. Das ist Architektur.

Was da steht

ikigai-gen ist ein AI-First Build-Server auf Hetzner. Jeder von uns — pwl, jkl, und die anderen — hat dort:

Einen eigenen Docker-Container als Arbeitsumgebung
Eine eigene Subdomain: pwl.ikigai-institut.de, jkl.ikigai-institut.de
Ein eigenes Git-Repository bei git.ikigai-institut.de
Einen Deployment-Webhook: push auf main → Site ist live, innerhalb von Sekunden

Der Server erkennt automatisch was du baust:

Was im Repo liegt	Was passiert
`hugo.toml`	Hugo baut die Site (wie hier)
`nuxt.config.ts`	Nuxt wird gebaut, läuft via pm2
sonst	Statische Files werden direkt deployed

Ihr müsst nichts konfigurieren. Ihr müsst kein Docker kennen. Ihr müsst keinen Admin fragen. Ihr pusht — es läuft.

Wie ihr anfangt

ssh pwl@168.119.163.185   # oder jkl@
# Passwort: changeme123!
# Ihr landet direkt in eurem Container

Lest als erstes ~/serverinfo — das erklärt alles.

2. SSH-Key hinterlegen (damit kein Passwort mehr nötig ist)

Das macht ihr einmalig selbst — copy, paste, fertig.

Lokal auf eurem Rechner:

# Key erzeugen (falls noch keiner da ist)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""

# Public Key anzeigen — diesen kopiert ihr
cat ~/.ssh/id_ed25519.pub

Im Container (nach SSH-Login):

mkdir -p ~/.ssh && chmod 700 ~/.ssh
# Den kopierten Key hier einfügen:
echo "ssh-ed25519 AAAA... euer-key" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Danach könnt ihr euch ohne Passwort einloggen.

3. Erstes Projekt anlegen

new-project meine-site static
# → erstellt Repo bei git.ikigai-institut.de/pwl/meine-site
# → konfiguriert https://meine-site.pwl.ikigai-institut.de
# → Webhook ist direkt aktiv

Dann:

cd ~/meine-site
echo "# Hallo Welt" > index.html
git add . && git commit -m "launch"
git push origin main
# → live.

Agenten, die füreinander arbeiten

Das Schöne an diesem Setup ist nicht die Infrastruktur. Das Schöne ist, was dadurch möglich wird.

Jeder von uns kann Agenten bauen, die auf dem Server arbeiten. Diese Agenten können:

Repos anlegen und deployen
PRs stellen und mergen
Subdomains provisionieren
miteinander via Git kommunizieren

Der Bot iki ist dafür reserviert — als interner Review-Agent der Plattform. Aber auch pwl und jkl können eigene Agenten laufen lassen.

Skills teilen

iki verwaltet eine kuratierte Skill-Bibliothek (privat, auf dem Server). Skills sind Prompt-Templates, die Agenten gezielt aufrufen. Wir haben gerade über 60 Skills gesammelt und in drei Tiers sortiert:

core/ — Grundlage: skill-creator, agent-development, frontend-design, playground, yeet, gh-fix-ci, …
extra/ — Spezialisiert: security, figma, notion, playwright, sora, vercel, netlify, …
community/ — Nischig: ikigai-server-admin, B2B-Strategie-Agenten, …

Wenn ihr eigene Skills baut — und das werdet ihr — könnt ihr sie als PR bei gai/agent-skills einreichen. Das gemeinsame Repo.

Was als nächstes

Ich würde vorschlagen:

Login und ~/serverinfo lesen
SSH-Key einmalig hinterlegen
Ein erstes Projekt mit new-project starten
Ein Skill bauen und bei gai/agent-skills einreichen

Ausblick: der selbstlernende Assistent

Etwas das ich noch einrichten will — und das ich euch schon mal auf den Schirm bringen möchte: Loop-Agenten.

/loop 30m /review

Die Idee: ein Agent läuft alle 30 Minuten, reviewt offene PRs, prüft ob Builds fehlgeschlagen sind, fasst zusammen was sich getan hat. Kein Polling von Hand. Der Agent übernimmt das Monitoring — und wird dabei besser, weil jede Runde eine Feedbackschleife ist.

Das ist noch nicht eingerichtet. Aber die Infrastruktur steht. Wer schneller ist — gerne.

Das System gehört uns allen. Es wächst dadurch, dass wir es benutzen.

Fragen, Ideen, PRs: einfach pushen.

— lip