Startklar

Referenz · Dateiformat v1

.klar.yml

Alles, was in der Datei stehen kann – und was Startklar daraus macht.

version: 1BeispielJSON SchemaMarkdown

Startklar ist eine Extension für mittwald mStudio. Eine Datei .klar.yml im Projekt beschreibt, was ein Projekt braucht: App, Datenbanken, Container, Cronjobs, Mail, Backups und Domains. Startklar richtet das im mStudio ein und hält es laufend so, wie es in der Datei steht.

Diese Seite beschreibt Version 1 des Dateiformats (version: 1). Sie liegt dauerhaft unter https://startklar.cyber.house/v1/, das JSON Schema unter https://startklar.cyber.house/v1/schema.json.

Status: Startklar ist in Entwicklung. Das Format ist festgelegt und wird geprüft, das Einrichten im mStudio entsteht gerade. Fragen, Fehler oder Wünsche: Kontakt.

Schnellstart

  1. Startklar in der Organisation im mStudio installieren und im Projekt aktivieren.
  2. Eine .klar.yml ins Repository legen und deployen, z.B. nach ~/html/prod/current/.
  3. Den neuen Fundort im Startklar-Menü des Projekts freigeben. Ab dann richtet Startklar alles ein und gleicht Änderungen automatisch ab.

Die kleinste gültige Datei:

# Startklar config — docs: https://startklar.cyber.house/v1/
# $schema: https://startklar.cyber.house/v1/schema.json
version: 1

Die zwei Kommentarzeilen sind optional, aber empfohlen: Die erste zeigt Menschen und KI-Agents, wo die Doku liegt, die zweite schaltet im Editor Autovervollständigung, Erklärungen beim Hovern und Prüfung ein – in VS Code und Cursor mit der YAML-Extension von Red Hat, in PhpStorm direkt.

Was eine Datei anlegt, zeigt der Editor: Datei einfügen, und daneben erscheinen Apps, Umgebungen, Datenbanken, Container und Domains – geprüft mit demselben Parser wie in der Extension.

Wie Startklar arbeitet

Alles außer version ist optional.

apps

Die Apps an diesem Fundort, nach frei wählbarem Namen (a-z, 0-9, -). Meist ist es eine, z.B. web. Ein Repository kann aber auch mehrere enthalten, etwa ein PHP-Backend und zwei Node-Frontends – mit target auch unterschiedlich pro Umgebung:

apps:
    backend:
        type: php # php, node, python, static
        version: "8.3" # nicht bei static
        documentRoot: public
        envFile: ../../shared/.env.local
        envValues: # eigene Werte für die envFile
            TYPO3_CONTEXT:
                prod: Production
                stage: Production/Staging
        software:
            composer: "2"
            imagemagick: latest
        phpExtensions: [excimer, apcu]
        phpIni:
            memory_limit: 512M
            session.save_handler: redis
            session.save_path: "tcp://${REDIS_HOST}:${REDIS_PORT}"
    shop:
        type: node
        version: "22"
        path: frontend/shop
        command: node server.js
    landing:
        type: node
        version: "22"
        path: frontend/landing
        command: node server.js
        target: prod # nur auf prod

Auf prod entstehen so drei Apps, auf stage zwei.

Feld Beschreibung
type php, node, python oder static
version Version in Anführungszeichen, sonst liest YAML 8.10 als Zahl 8.1
path Verzeichnis der App relativ zur Datei; Standard: das Verzeichnis der Datei
target nur an diesen Fundorten, siehe target
documentRoot relativ zur Datei, z.B. public; Pflicht bei php und static, bei node und python nicht vorhanden
command nur node und python: Startbefehl
envFile Pfad der .env-Datei der App, siehe Variablen
envValues eigene Werte zusätzlich zu den Zugangsdaten, siehe Variablen
software zusätzliche Systemsoftware mit Version; entfernte Einträge werden deinstalliert
phpExtensions nur php: einzuschaltende Erweiterungen
phpIni nur php: php.ini-Werte, ${NAME} wird ersetzt

Zwei Apps dürfen am selben Fundort nicht im selben Verzeichnis liegen. Gibt es mehr als eine App, geben routing und cronjobs mit app an, welche gemeint ist.

php.ini: Die Werte landen in /tmp/php/php.ini. Diese Datei gilt für das ganze Projekt: Setzen zwei Fundorte unterschiedliche Werte für denselben Schlüssel, meldet Startklar einen Konflikt und schreibt nichts. Startklar schreibt die Datei nur, wenn sich der Inhalt ändert, weil jedes Schreiben PHP neu startet.

databases

MySQL- und Redis-Datenbanken, nach frei wählbarem Namen (a-z, 0-9, -).

databases:
    db:
        type: mysql
        version: "8.4"
        charset: utf8mb4
        collation: utf8mb4_unicode_ci
        target: [prod, stage]
        envValues:
            DB_HOST: ${host}
            DB_PORT: ${port}
            DB_NAME: ${name}
            DB_USER: ${user}
            DB_PASSWORD: ${password}
    cache:
        type: redis
        version: "7.2"
        shared: true
        maxMemory: 512mb
        maxMemoryPolicy: allkeys-lru
        persistent: false
        envValues:
            REDIS_HOST: ${host}
            REDIS_PORT: ${port}
Feld MySQL Redis Beschreibung
type mysql redis
version ✓ ✓ in Anführungszeichen
charset, collation ✓
maxMemory ✓ z.B. 512mb
maxMemoryPolicy ✓ noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random, volatile-ttl
persistent ✓ Daten auf Platte sichern
shared, target ✓ ✓ siehe target und shared
envValues ${…}: host, port, name, user, password ${…}: host, port siehe Variablen

containers

Container nach Name.

containers:
    solr:
        image: ghcr.io/acme/solr:9.6
        port: 8983
        shared: true
        volumes:
            - solr-data:/var/solr
        limits:
            cpus: "1"
            memory: 2g
        secrets:
            - SOLR_PASSWORD
        envValues:
            SOLR_HOST: ${host}
            SOLR_PORT: ${port}
            SOLR_PASSWORD: ${SOLR_PASSWORD}
    worker:
        image: ghcr.io/acme/worker:1.4
        target: prod # nur auf prod
        command: ["php", "bin/worker", "--queue=default"]
        environment:
            DATABASE_URL: "mysql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}/${DB_NAME}"
            LOG_LEVEL: info
Feld Beschreibung
image Docker-Image; private Registries siehe registries
port Port, auf dem der Container lauscht
command Befehl als Liste, statt dem Standardbefehl des Images
environment Variablen im Container, für das Programm darin; ${NAME} meint eine Variable aus den envValues einer Ressource
volumes "<name>:<pfad im container>"
limits cpus, memory
secrets siehe unten
envValues Variablen für die Apps, in deren envFile; ${…}: host, port und Namen von Secrets
shared, target siehe target und shared

environment und envValues gehen in entgegengesetzte Richtungen: environment konfiguriert den Container selbst (z.B. bekommt der Worker die DATABASE_URL), envValues sagt den Apps, wie sie den Container erreichen (z.B. bekommt die TYPO3-App SOLR_HOST in ihre .env). Ein Container kann beides brauchen.

An eine gemeinsame Instanz hängen: Liegen mehrere Repositories im selben Projekt – jedes mit eigener .klar.yml –, kann eines einen Container mit shared: true definieren und die anderen hängen sich nur an. Ein Eintrag ohne image legt nichts an, sondern nutzt die gleichnamige Instanz und bekommt deren Zugangsdaten in die eigene envFile. Erlaubt sind dann nur shared, target und envValues:

# ~/html/website/.klar.yml – definiert die Instanz
containers:
    solr:
        image: solr:9.6
        port: 8983
        shared: true
        secrets: [SOLR_PASSWORD]
        envValues:
            SOLR_HOST: ${host}
            SOLR_PASSWORD: ${SOLR_PASSWORD}
# ~/html/shop/.klar.yml – hängt sich nur an
containers:
    solr:
        shared: true
        envValues:
            SOLR_HOST: ${host}
            SOLR_PASSWORD: ${SOLR_PASSWORD}

Definiert keine Datei im Projekt die Instanz, wird der Eintrag nicht angewendet und das Startklar-Menü zeigt es an.

Secrets

Startklar erzeugt Secrets einmalig, speichert sie verschlüsselt, übergibt sie dem Container als Umgebungsvariable und schreibt sie über die envValues des Containers (z.B. SOLR_PASSWORD: ${SOLR_PASSWORD}) in die envFile jeder App, die den Container nutzt – auch bei gemeinsamen Instanzen.

secrets:
    - SOLR_PASSWORD # 32 Zeichen, A-Z a-z 0-9
    - name: LEGACY_API_PASSWORD
      length: 12 # 8 bis 256
      chars: "A-Za-z0-9!#%" # wie eine Regex-Zeichenklasse
      pattern: "^[A-Za-z].*[0-9]" # wird neu erzeugt, bis es passt

smtp

Ein Postfach zum Versenden von Mails aus der App – für alles, was die App selbst verschickt, z.B. Kontaktformulare oder Passwort-Links. Startklar legt das Postfach an und schreibt die Zugangsdaten in die envFile.

smtp:
    envValues:
        SMTP_HOST: ${host}
        SMTP_PORT: ${port}
        SMTP_USER: ${user}
        SMTP_PASSWORD: ${password}

Mit shared und target wie bei Datenbanken.

cronjobs

Cronjobs nach Name, ausgeführt in einer App des Fundorts. Gibt es mehrere Apps, sagt app, in welcher.

cronjobs:
    scheduler:
        schedule: "*/5 * * * *"
        command: vendor/bin/typo3 scheduler:run
        app: backend # nur nötig bei mehreren Apps
        target: prod
        timeout: 600
        timezone: Europe/Vienna
        email: ops@acme.at
Feld Beschreibung
schedule Cron-Zeitplan mit 5 Feldern, in Anführungszeichen
command Befehl, im Verzeichnis der App
app App aus apps; nur nötig bei mehreren Apps
timeout Sekunden
timezone z.B. Europe/Vienna
email Benachrichtigung bei Fehlern

backups

Backup-Zeitpläne für das ganze Projekt. Definieren mehrere Dateien Backups, müssen sie übereinstimmen, sonst meldet Startklar einen Konflikt. Ohne backups bleiben die Einstellungen des Projekts unverändert.

backups:
    - schedule: "0 3 * * *"
      keep: 14d

registries

Nur nötig, wenn Container-Images aus einer privaten Registry kommen, z.B. eigene Images auf ghcr.io; öffentliche Images wie auf Docker Hub brauchen keinen Eintrag. Angegeben wird nur der Hostname. Die Zugangsdaten stehen nicht in der Datei, sondern werden einmal pro Organisation im Startklar-Menü hinterlegt.

registries:
    - ghcr.io

routing

Domains als Liste von Einträgen. Jeder Eintrag zeigt auf eine App, einen Container oder leitet weiter. Auch Hunderte Domains bleiben so übersichtlich. TLS-Zertifikate kommen automatisch von Let's Encrypt.

routing:
    - domains: [www.acme.at, www.acme.de]
      target: prod
    - domains: [stage.acme.at]
      target: stage
    - domains: [shop.acme.at]
      app: shop # nur nötig bei mehreren Apps
      target: prod
    - domains: [www.acme.at/search]
      container: solr
    - domains: [acme.at, acme.de]
      redirect: https://www.{domain}
    - domains: [acme-online.at]
      redirect: https://www.acme.at
Art Felder Regeln
App target, bei mehreren Apps app genau ein Verzeichnis; die App muss dort existieren
Container container, optional target, port target ist Pflicht, wenn der Container nicht shared ist; port, wenn der Container keinen hat
Weiterleitung redirect nicht mit target, app oder container kombinierbar

target

Meist liegt dieselbe Datei in mehreren Verzeichnissen, z.B. für prod und stage. Jeder Fundort bekommt eigene Apps und eigene Ressourcen. Mit target gilt ein Eintrag nur für bestimmte Fundorte:

cronjobs:
    scheduler:
        schedule: "*/5 * * * *"
        command: vendor/bin/typo3 scheduler:run
        target: prod # oder eine Liste: [prod, stage]

Ohne target gilt ein Eintrag überall. Im routing ist genau ein Ziel erlaubt, weil eine Domain nur auf eine App an einem Fundort zeigen kann.

targets

Welcher Fundort welches target ist, lässt sich auf zwei Arten festlegen:

Ohne targets: Ein target ist das gleichnamige Verzeichnis direkt unter ~/html. target: prod passt auf ~/html/prod/.klar.yml und ~/html/prod/current/.klar.yml – nicht auf preprod.

Mit targets (optional, empfohlen): Die Umgebungen stehen oben in der Datei, jeweils mit ihrem Verzeichnis:

targets:
    prod: ~/html/path/to/prod
    stage: ~/html/path/to/stage-new

shared

Standardmäßig bekommt jeder Fundort eigene Datenbanken, Container und SMTP-Postfächer. Mit shared: true gibt es eine Instanz für das ganze Projekt, verbunden über den Namen:

databases:
    cache:
        type: redis
        version: "7.2"
        shared: true # ein Redis für prod und stage

shared ist nie der Standard. Eine Datei kann sich an eine gemeinsame Instanz hängen, die in einer anderen Datei definiert ist, siehe Container.

Pfade

Alle Pfade sind relativ zum echten Ort der .klar.yml, so wie sie im Dateisystem liegt. Bei Deployments mit Releases ist das ~/html/prod/releases/<id>/, erreicht über den Symlink current.

Angabe Bedeutung
documentRoot: public ~/html/prod/current/public – Pfade im Release werden auf current/… abgebildet
envFile: ../../shared/.env.local ~/html/prod/shared/.env.local – Pfade außerhalb bleiben, wie sie sind

Eine App ohne path wird im Verzeichnis oberhalb von current installiert, also ~/html/prod. Mit path: frontend/shop liegt sie in ~/html/prod/current/frontend/shop.

Variablen

Jede App kann eine .env-Datei bekommen. Was hineinkommt, steht überall gleich als envValues – immer NAME: wert:

Wo Was Landet in
envFile bei der App wohin: Pfad der .env-Datei, relativ zur .klar.yml –
envValues bei Datenbanken, Redis, Containern, smtp Zugangsdaten und Werte dieser Ressource der envFile jeder App an den targets der Ressource – automatisch
envValues bei der App eigene Werte nur der envFile dieser App 
.env der App  =  envValues aller Ressourcen, die an diesem Fundort gelten (automatisch)
              +  envValues der App

Startklar verwaltet in der Datei nur den Abschnitt zwischen #startklar und #endklar. Alles andere bleibt unverändert:

APP_ENV=prod
#startklar
DB_HOST=mysql-abc123.pg-s-xyz.db.project.host
DB_PASSWORD=…
TYPO3_CONTEXT=Production
#endklar

An Ressourcen

In den envValues einer Ressource meint ${…} ein Feld dieser Ressource. So kommen Zugangsdaten unter dem Namen in die .env, den die App erwartet – auch zusammengesetzt oder als fester Wert:

databases:
    db:
        type: mysql
        version: "8.4"
        envValues:
            DB_HOST: ${host}
            DB_PASSWORD: ${password}
            DATABASE_URL: "mysql://${user}:${password}@${host}/${name}"
Ressource Felder für ${…}
MySQL host, port, name, user, password
Redis host, port
Container host, port (wenn angegeben) und die Namen seiner secrets
smtp host, port, user, password

An Apps

Eigene Werte für die envFile einer App – z.B. den Kontext pro Umgebung, sodass in der .env.local nichts mehr von Hand gepflegt werden muss:

apps:
    backend:
        type: php
        version: "8.3"
        documentRoot: public
        envFile: ../../shared/.env.local
        envValues:
            TYPO3_CONTEXT: # ein Wert pro target
                prod: Production
                stage: Production/Staging
            LOG_LEVEL: info # überall gleich

Regeln

Reihenfolge

Platzhalter brauchen die echten Werte. Startklar geht deshalb bei jedem Abgleich in dieser Reihenfolge vor:

  1. Secrets erzeugen
  2. Datenbanken, Redis und SMTP-Postfach anlegen und warten, bis sie bereit sind
  3. Container anlegen – mit aufgelösten Platzhaltern in environment
  4. Apps anlegen, samt Software und PHP-Erweiterungen
  5. envFile schreiben – envValues der Ressourcen und der App
  6. php.ini schreiben – mit aufgelösten Platzhaltern
  7. Cronjobs, Routing und Backups
  8. STARTKLAR_HASH in die envFile schreiben (siehe Im Deploy warten)

Fehlt für einen Platzhalter der Wert, weil die zugehörige Ressource noch nicht bereit ist, schreibt Startklar weder die php.ini noch den betroffenen Container noch den Hash und versucht es später erneut. Eine halb aufgelöste Einstellung wie tcp://: entsteht so nie.

Was Startklar ändert und löscht

Fall Verhalten
Neuer Eintrag wird angelegt
Geänderter Eintrag wird angepasst
Entfernte Einstellung ohne Daten (Software, PHP-Erweiterung, Cronjob, Variable, Container-Konfiguration) wird automatisch entfernt
Entfernte Ressource mit Daten oder sichtbarer Wirkung (Datenbank, Redis, Container mit Volume, Domain, App) wird erst nach Bestätigung im Startklar-Menü entfernt
Ungültige Datei nichts wird geändert, Fehler mit Zeilennummer im Menü
Konflikt zwischen Dateien (Domain doppelt, php.ini, Backups) betroffener Teil wird nicht angewendet, Konflikt im Menü

Startklar ändert nur, was es selbst angelegt hat.

Aufräumen (Projekt-Einstellung)

Wer es aufgeräumt haben will, kann im Startklar-Menü des Projekts einstellen, dass Ressourcen ohne Eintrag in einer .klar.yml automatisch entfernt werden – pro Art einzeln, standardmäßig ist alles aus. Die Einstellung steht bewusst nicht in der Datei: Ein Commit allein soll nie Daten löschen können.

Einstellung Verhalten
Domains werden entfernt
Container ohne Volumes werden entfernt
Container mit Volumes, Datenbanken, Redis werden zum Löschen vorgemerkt und nach 24 Stunden entfernt; bis dahin im Menü abbrechbar
Auch nicht von Startklar angelegte Ressourcen gilt zusätzlich für Ressourcen, die von Hand angelegt wurden

Unabhängig davon gilt immer:

Prüfung und Fehler

Startklar prüft die Datei vollständig, bevor es etwas tut. Jeder Fehler kommt mit Pfad und Zeile, z.B.:

routing[1].domains[0] (Zeile 84): www.acme.at kommt schon in routing[0] vor

Unbekannte Schlüssel sind Fehler, damit Tippfehler wie docRoot statt documentRoot auffallen.

Im Deploy warten

Startklar bemerkt eine geänderte .klar.yml innerhalb von 15 Sekunden nach dem Deploy und gleicht sie dann ab, einen neuen Fundort erst nach der Freigabe im Menü. Damit z.B. Datenbank-Migrationen beim ersten Aufsetzen erst laufen, wenn die Datenbank existiert, wartet Startklar nach dem Anlegen, bis mittwald jede Ressource als bereit meldet (Datenbanken und Redis ready, Apps ready, Container running), und schreibt erst dann – als letzten Schritt – den Hash der angewendeten Datei in den eigenen Block der envFile. Auf Domains und TLS-Zertifikate wird dabei nicht gewartet, ihren Stand zeigt das Startklar-Menü:

#startklar
DB_HOST=…
DB_PASSWORD=…
STARTKLAR_HASH=3f9a…
#endklar

Steht dort der Hash der aktuellen .klar.yml, ist alles angewendet – auch die Zugangsdaten in derselben Datei. Warten lässt sich darauf mit Bordmitteln, im Verzeichnis der .klar.yml (z.B. im Deploy nach dem Umschalten von current, vor den Migrationen):

timeout 99 sh -c 'until grep -q $(sha256sum .klar.yml | cut -c-64) ../../shared/.env.local; do sleep 5; done'

Fehler in der Datei selbst lassen sich schon vor dem Deploy erkennen – im Editor dank der $schema-Zeile oder in der Pipeline mit einem beliebigen JSON-Schema-Validator, z.B.:

pipx run check-jsonschema --schemafile https://startklar.cyber.house/v1/schema.json .klar.yml

Ändert sich ein Dienst, kann es während des Abgleichs kurz eine Downtime geben – das Warten verhindert nur, dass der Deploy in dieser Zeit weiterläuft.

Berechtigungen und Sicherheit

Was Startklar nicht macht

Für KI-Agents

Wenn du als KI-Agent eine .klar.yml bearbeitest:

Beispiel

Ein vollständiges Beispiel mit allen Funktionen: TYPO3-Backend und zwei Node-Frontends, deployt nach ~/html/prod und ~/html/stage. Fahre über einen Eintrag – oder tippe ihn an –, um zu sehen, was er bewirkt. Zum Herunterladen: example.klar.yml.

.klar.ymlFahre über einen Eintrag oder tippe ihn an
# Startklar config — docs: https://startklar.cyber.house/v1/# $schema: https://startklar.cyber.house/v1/schema.json## Example with every feature: TYPO3 backend plus two# Node frontends, deployed via Magallanes.# Everything except "version" is optional, missing# sections are not touched. Paths are relative to# the real location of this file (releases/<id>).versionversionVersion des DateiformatsMehr in der Doku →: 1
# Optional: environments and their deploy directories.# Without it, "target: prod" means ~/html/prod.targetstargetsOptional: Umgebungen mit Name und Verzeichnis, z.B. prod: ~/html/path/to/prod. Dann gelten genau diese Pfade, und an anderen Fundorten wendet Startklar nichts an. Ohne targets ist ein target das gleichnamige Verzeichnis direkt unter ~/html.Mehr in der Doku →:    prodtargets.prodUmgebung „prod“ und ihr Verzeichnis (mit oder ohne current). Einträge mit target: prod gelten nur dort.Mehr in der Doku →: ~/html/prod    stagetargets.stageUmgebung „stage“ und ihr Verzeichnis (mit oder ohne current). Einträge mit target: stage gelten nur dort.Mehr in der Doku →: ~/html/acme/staging
appsappsApps an diesem Fundort, nach Name, z.B. backend und shop. Mit target pro Umgebung einschränkbarMehr in der Doku →:    backendapps.backendName der App „backend“, frei wählbar (a-z, 0-9, -). Routing und Cronjobs verweisen mit app: backend darauf.Mehr in der Doku →:        typeapps.backend.typeArt der AppWerte: php, node, python, staticMehr in der Doku →: php        versionapps.backend.versionVersion der Laufzeitumgebung in Anführungszeichen, z.B. "8.3" (nicht bei static)Mehr in der Doku →: "8.3"        documentRootapps.backend.documentRootDocument Root relativ zur .klar.yml, z.B. public. Pflicht bei php und static, bei node und python nicht vorhandenMehr in der Doku →: public        # Startklar only writes its own block in this file        envFileapps.backend.envFileDatei, in die Startklar die envValues der Ressourcen und der App schreibt (Abschnitt zwischen #startklar und #endklar), relativ zur .klar.yml, z.B. ../../shared/.env.localMehr in der Doku →: ../../shared/.env.local        # Own values for this envFile, in addition to the credentials        envValuesapps.backend.envValuesEigene Werte für die envFile dieser App, zusätzlich zu den envValues der Ressourcen: ein Wert für überall oder ein Wert pro target. ${NAME} meint eine Variable aus den envValues einer RessourceMehr in der Doku →:            TYPO3_CONTEXTapps.backend.envValues.TYPO3_CONTEXTTYPO3_CONTEXT: kommt zusätzlich in die envFile dieser App – ein Wert für überall oder einer pro target.Mehr in der Doku →:                prodapps.backend.envValues.TYPO3_CONTEXT.prodWert von TYPO3_CONTEXT am target prod. An targets ohne Eintrag wird TYPO3_CONTEXT nicht gesetzt.Mehr in der Doku →: Production                stageapps.backend.envValues.TYPO3_CONTEXT.stageWert von TYPO3_CONTEXT am target stage. An targets ohne Eintrag wird TYPO3_CONTEXT nicht gesetzt.Mehr in der Doku →: Production/Staging            LOG_LEVELapps.backend.envValues.LOG_LEVELLOG_LEVEL: kommt zusätzlich in die envFile dieser App – ein Wert für überall oder einer pro target.Mehr in der Doku →: info        softwareapps.backend.softwareZusätzliche Systemsoftware mit Version, z.B. composer: "2", imagemagick: latestMehr in der Doku →:            composerapps.backend.software.composerSystemsoftware composer mit Version. Wird sie aus der Datei entfernt, deinstalliert Startklar sie.Mehr in der Doku →: "2"            imagemagickapps.backend.software.imagemagickSystemsoftware imagemagick mit Version. Wird sie aus der Datei entfernt, deinstalliert Startklar sie.Mehr in der Doku →: latest        phpExtensionsapps.backend.phpExtensionsNur bei type: php. Einzuschaltende PHP-ErweiterungenMehr in der Doku →:            - excimer            - apcu        # Global for the project; ${NAME} from the envValues of a resource        phpIniapps.backend.phpIniNur bei type: php. php.ini-Werte (projektweit), ${NAME} meint eine Variable aus den envValues einer RessourceMehr in der Doku →:            memory_limitapps.backend.phpIni.memory_limitphp.ini-Einstellung memory_limit. Landet in /tmp/php/php.ini und gilt für das ganze Projekt.Mehr in der Doku →: 512M            max_execution_timeapps.backend.phpIni.max_execution_timephp.ini-Einstellung max_execution_time. Landet in /tmp/php/php.ini und gilt für das ganze Projekt.Mehr in der Doku →: 120            upload_max_filesizeapps.backend.phpIni.upload_max_filesizephp.ini-Einstellung upload_max_filesize. Landet in /tmp/php/php.ini und gilt für das ganze Projekt.Mehr in der Doku →: 64M            post_max_sizeapps.backend.phpIni.post_max_sizephp.ini-Einstellung post_max_size. Landet in /tmp/php/php.ini und gilt für das ganze Projekt.Mehr in der Doku →: 64M            session.save_handlerapps.backend.phpIni.session.save_handlerphp.ini-Einstellung session.save_handler. Landet in /tmp/php/php.ini und gilt für das ganze Projekt.Mehr in der Doku →: redis            session.save_pathapps.backend.phpIni.session.save_pathphp.ini-Einstellung session.save_path. Landet in /tmp/php/php.ini und gilt für das ganze Projekt.Mehr in der Doku →: "tcp://${REDIS_HOST}:${REDIS_PORT}"    shopapps.shopName der App „shop“, frei wählbar (a-z, 0-9, -). Routing und Cronjobs verweisen mit app: shop darauf.Mehr in der Doku →:        typeapps.shop.typeArt der AppWerte: php, node, python, staticMehr in der Doku →: node        versionapps.shop.versionVersion der Laufzeitumgebung in Anführungszeichen, z.B. "8.3" (nicht bei static)Mehr in der Doku →: "22"        pathapps.shop.pathVerzeichnis der App relativ zur .klar.yml, z.B. frontend/shop. Standard: das Verzeichnis der .klar.ymlMehr in der Doku →: frontend/shop        commandapps.shop.commandNur bei node und python: Startbefehl, z.B. node server.jsMehr in der Doku →: node server.js        envFileapps.shop.envFileDatei, in die Startklar die envValues der Ressourcen und der App schreibt (Abschnitt zwischen #startklar und #endklar), relativ zur .klar.yml, z.B. ../../shared/.env.localMehr in der Doku →: ../../shared/frontend/shop/.env.local    landingapps.landingName der App „landing“, frei wählbar (a-z, 0-9, -). Routing und Cronjobs verweisen mit app: landing darauf.Mehr in der Doku →:        typeapps.landing.typeArt der AppWerte: php, node, python, staticMehr in der Doku →: node        versionapps.landing.versionVersion der Laufzeitumgebung in Anführungszeichen, z.B. "8.3" (nicht bei static)Mehr in der Doku →: "22"        pathapps.landing.pathVerzeichnis der App relativ zur .klar.yml, z.B. frontend/shop. Standard: das Verzeichnis der .klar.ymlMehr in der Doku →: frontend/landing        commandapps.landing.commandNur bei node und python: Startbefehl, z.B. node server.jsMehr in der Doku →: node server.js        targetapps.landing.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: prod # only on prod
databasesdatabasesMySQL- und Redis-Datenbanken, nach NameMehr in der Doku →:    dbdatabases.dbName der Datenbank „db“, frei wählbar (a-z, 0-9, -). Bei shared: true verbindet dieser Name die Fundorte.Mehr in der Doku →:        typedatabases.db.typeArt der Datenbank: mysql oder redisMehr in der Doku →: mysql        versiondatabases.db.versionMySQL-Version, z.B. "8.4"Mehr in der Doku →: "8.4"        charsetdatabases.db.charsetZeichensatz der Datenbank, z.B. utf8mb4Mehr in der Doku →: utf8mb4        collationdatabases.db.collationSortierung der Datenbank, z.B. utf8mb4_unicode_ciMehr in der Doku →: utf8mb4_unicode_ci        envValuesdatabases.db.envValuesVariablen für die envFile jeder App an den targets dieser Ressource, z.B. DB_HOST: ${host}. ${…} meint ein Feld dieser Ressource: host, port, name, user, passwordMehr in der Doku →:            DB_HOSTdatabases.db.envValues.DB_HOSTDB_HOST: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${host}            DB_PORTdatabases.db.envValues.DB_PORTDB_PORT: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${port}            DB_NAMEdatabases.db.envValues.DB_NAMEDB_NAME: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${name}            DB_USERdatabases.db.envValues.DB_USERDB_USER: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${user}            DB_PASSWORDdatabases.db.envValues.DB_PASSWORDDB_PASSWORD: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${password}    cachedatabases.cacheName der Datenbank „cache“, frei wählbar (a-z, 0-9, -). Bei shared: true verbindet dieser Name die Fundorte.Mehr in der Doku →:        typedatabases.cache.typeArt der Datenbank: mysql oder redisMehr in der Doku →: redis        versiondatabases.cache.versionRedis-Version, z.B. "7.2"Mehr in der Doku →: "7.2"        shareddatabases.cache.sharedtrue: eine gemeinsame Instanz für alle Fundorte im Projekt, über den Namen verbunden. Standard: false (eine Instanz pro Fundort).Mehr in der Doku →: true # one Redis for prod and stage        maxMemorydatabases.cache.maxMemoryMaximaler Speicher, z.B. "512mb"Mehr in der Doku →: 512mb        maxMemoryPolicydatabases.cache.maxMemoryPolicyWas Redis löscht, wenn maxMemory erreicht istWerte: noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random, volatile-ttlMehr in der Doku →: allkeys-lru        persistentdatabases.cache.persistentDaten auf Platte sichernMehr in der Doku →: false        envValuesdatabases.cache.envValuesVariablen für die envFile jeder App an den targets dieser Ressource, z.B. DB_HOST: ${host}. ${…} meint ein Feld dieser Ressource: host, portMehr in der Doku →:            REDIS_HOSTdatabases.cache.envValues.REDIS_HOSTREDIS_HOST: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${host}            REDIS_PORTdatabases.cache.envValues.REDIS_PORTREDIS_PORT: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${port}
# Credentials go into the Startklar UI, not hereregistriesregistriesPrivate Registries (Hostname); Zugangsdaten werden im Startklar-UI hinterlegtMehr in der Doku →:    - ghcr.io
containerscontainersContainer, nach NameMehr in der Doku →:    solrcontainers.solrName des Containers „solr“, frei wählbar (a-z, 0-9, -). Darauf verweist das Routing; bei shared: true verbindet der Name die Fundorte.Mehr in der Doku →:        imagecontainers.solr.imageDocker-Image, z.B. ghcr.io/acme/solr:9.6. Ohne image (nur mit shared: true) wird eine anderswo definierte Instanz genutzt.Mehr in der Doku →: ghcr.io/acme/solr:9.6        portcontainers.solr.portPort, auf dem der Container lauschtMehr in der Doku →: 8983        sharedcontainers.solr.sharedtrue: eine gemeinsame Instanz für alle Fundorte im Projekt, über den Namen verbunden. Standard: false (eine Instanz pro Fundort).Mehr in der Doku →: true # one instance for prod and stage        volumescontainers.solr.volumesVolumes als "<name>:<pfad im container>"Mehr in der Doku →:            - solr-data:/var/solr        limitscontainers.solr.limitsRessourcen-Grenzen des ContainersMehr in der Doku →:            cpuscontainers.solr.limits.cpusMaximale CPU-Kerne, z.B. "1" oder "0.5"Mehr in der Doku →: "1"            memorycontainers.solr.limits.memoryMaximaler Arbeitsspeicher, z.B. 2g oder 512mMehr in der Doku →: 2g        secretscontainers.solr.secretsVon Startklar einmalig erzeugte Secrets, als Umgebungsvariablen an den Container übergebenMehr in der Doku →:            - SOLR_PASSWORD # generated once, 32 chars        envValuescontainers.solr.envValuesVariablen für die envFile jeder App an den targets dieser Ressource, z.B. DB_HOST: ${host}. ${…} meint ein Feld dieser Ressource: host, port und die Namen der secretsMehr in der Doku →:            SOLR_HOSTcontainers.solr.envValues.SOLR_HOSTSOLR_HOST: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${host}            SOLR_PORTcontainers.solr.envValues.SOLR_PORTSOLR_PORT: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${port}            SOLR_PASSWORDcontainers.solr.envValues.SOLR_PASSWORDSOLR_PASSWORD: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${SOLR_PASSWORD}    workercontainers.workerName des Containers „worker“, frei wählbar (a-z, 0-9, -). Darauf verweist das Routing; bei shared: true verbindet der Name die Fundorte.Mehr in der Doku →:        imagecontainers.worker.imageDocker-Image, z.B. ghcr.io/acme/solr:9.6. Ohne image (nur mit shared: true) wird eine anderswo definierte Instanz genutzt.Mehr in der Doku →: ghcr.io/acme/worker:1.4        targetcontainers.worker.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: prod        commandcontainers.worker.commandBefehl statt dem Standardbefehl des ImagesMehr in der Doku →: ["php", "bin/worker", "--queue=default"]        environmentcontainers.worker.environmentUmgebungsvariablen im Container selbst, ${NAME} meint eine Variable aus den envValues einer RessourceMehr in der Doku →:            DATABASE_URLcontainers.worker.environment.DATABASE_URLUmgebungsvariable DATABASE_URL im Container selbst. ${NAME} im Wert meint eine Variable aus den envValues einer Ressource.Mehr in der Doku →: "mysql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}/${DB_NAME}"            REDIS_URLcontainers.worker.environment.REDIS_URLUmgebungsvariable REDIS_URL im Container selbst. ${NAME} im Wert meint eine Variable aus den envValues einer Ressource.Mehr in der Doku →: "redis://${REDIS_HOST}:${REDIS_PORT}"            LOG_LEVELcontainers.worker.environment.LOG_LEVELUmgebungsvariable LOG_LEVEL im Container selbst. ${NAME} im Wert meint eine Variable aus den envValues einer Ressource.Mehr in der Doku →: info    legacy-apicontainers.legacy-apiName des Containers „legacy-api“, frei wählbar (a-z, 0-9, -). Darauf verweist das Routing; bei shared: true verbindet der Name die Fundorte.Mehr in der Doku →:        imagecontainers.legacy-api.imageDocker-Image, z.B. ghcr.io/acme/solr:9.6. Ohne image (nur mit shared: true) wird eine anderswo definierte Instanz genutzt.Mehr in der Doku →: ghcr.io/acme/legacy-api:2.1        portcontainers.legacy-api.portPort, auf dem der Container lauschtMehr in der Doku →: 8080        targetcontainers.legacy-api.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: prod        secretscontainers.legacy-api.secretsVon Startklar einmalig erzeugte Secrets, als Umgebungsvariablen an den Container übergebenMehr in der Doku →:            - namecontainers.legacy-api.secrets[0].nameName des SecretsMehr in der Doku →: LEGACY_API_PASSWORD              lengthcontainers.legacy-api.secrets[0].lengthLänge, Standard 32Mehr in der Doku →: 12              charscontainers.legacy-api.secrets[0].charsErlaubte Zeichen wie in einer Regex-Zeichenklasse, z.B. "A-Za-z0-9!#%"Mehr in der Doku →: "A-Za-z0-9!#%"              patterncontainers.legacy-api.secrets[0].patternRegulärer Ausdruck, den das Secret erfüllen muss; es wird neu erzeugt, bis er passt.Mehr in der Doku →: "^[A-Za-z].*[0-9]"        envValuescontainers.legacy-api.envValuesVariablen für die envFile jeder App an den targets dieser Ressource, z.B. DB_HOST: ${host}. ${…} meint ein Feld dieser Ressource: host, port und die Namen der secretsMehr in der Doku →:            LEGACY_API_HOSTcontainers.legacy-api.envValues.LEGACY_API_HOSTLEGACY_API_HOST: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${host}            LEGACY_API_PORTcontainers.legacy-api.envValues.LEGACY_API_PORTLEGACY_API_PORT: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${port}            LEGACY_API_PASSWORDcontainers.legacy-api.envValues.LEGACY_API_PASSWORDLEGACY_API_PASSWORD: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${LEGACY_API_PASSWORD}    mailpitcontainers.mailpitName des Containers „mailpit“, frei wählbar (a-z, 0-9, -). Darauf verweist das Routing; bei shared: true verbindet der Name die Fundorte.Mehr in der Doku →:        imagecontainers.mailpit.imageDocker-Image, z.B. ghcr.io/acme/solr:9.6. Ohne image (nur mit shared: true) wird eine anderswo definierte Instanz genutzt.Mehr in der Doku →: axllent/mailpit:v1.21        portcontainers.mailpit.portPort, auf dem der Container lauschtMehr in der Doku →: 8025        targetcontainers.mailpit.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: stage
smtpsmtpPostfach zum Versenden von Mails (SMTP)Mehr in der Doku →:    targetsmtp.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: prod    envValuessmtp.envValuesVariablen für die envFile jeder App an den targets dieser Ressource, z.B. DB_HOST: ${host}. ${…} meint ein Feld dieser Ressource: host, port, user, passwordMehr in der Doku →:        SMTP_HOSTsmtp.envValues.SMTP_HOSTSMTP_HOST: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${host}        SMTP_PORTsmtp.envValues.SMTP_PORTSMTP_PORT: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${port}        SMTP_USERsmtp.envValues.SMTP_USERSMTP_USER: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${user}        SMTP_PASSWORDsmtp.envValues.SMTP_PASSWORDSMTP_PASSWORD: kommt in die envFile jeder App an den targets dieser Ressource. ${…} meint ein Feld dieser Ressource, z.B. ${host}.Mehr in der Doku →: ${password}
cronjobscronjobsCronjobs, nach NameMehr in der Doku →:    schedulercronjobs.schedulerName des Cronjobs „scheduler“, frei wählbar.Mehr in der Doku →:        schedulecronjobs.scheduler.scheduleCron-Zeitplan, z.B. "*/5 * * * *"Mehr in der Doku →: "*/5 * * * *"        commandcronjobs.scheduler.commandBefehl, relativ zum Verzeichnis der AppMehr in der Doku →: vendor/bin/typo3 scheduler:run        appcronjobs.scheduler.appApp, in der der Cronjob läuft; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: backend        targetcronjobs.scheduler.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: prod        timeoutcronjobs.scheduler.timeoutTimeout in SekundenMehr in der Doku →: 600        timezonecronjobs.scheduler.timezonez.B. Europe/ViennaMehr in der Doku →: Europe/Vienna        emailcronjobs.scheduler.emailBenachrichtigung bei FehlernMehr in der Doku →: ops@acme.at    cache-warmupcronjobs.cache-warmupName des Cronjobs „cache-warmup“, frei wählbar.Mehr in der Doku →:        schedulecronjobs.cache-warmup.scheduleCron-Zeitplan, z.B. "*/5 * * * *"Mehr in der Doku →: "0 6 * * *"        commandcronjobs.cache-warmup.commandBefehl, relativ zum Verzeichnis der AppMehr in der Doku →: vendor/bin/typo3 cache:warmup        appcronjobs.cache-warmup.appApp, in der der Cronjob läuft; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: backend        targetcronjobs.cache-warmup.targetNur bei diesen targets anwenden, z.B. prod oder [prod, stage]: Namen aus targets oben, sonst Verzeichnisse direkt unter ~/html. Ohne target: überall.Mehr in der Doku →: [prod, stage]
# Project-wide: all files must agreebackupsbackupsBackup-Zeitpläne für das ProjektMehr in der Doku →:    - schedulebackups[0].scheduleCron-Zeitplan, z.B. "0 3 * * *"Mehr in der Doku →: "0 3 * * *"      keepbackups[0].keepAufbewahrung in Tagen, z.B. "14d"Mehr in der Doku →: 14d    - schedulebackups[1].scheduleCron-Zeitplan, z.B. "0 3 * * *"Mehr in der Doku →: "0 4 * * 0"      keepbackups[1].keepAufbewahrung in Tagen, z.B. "14d"Mehr in der Doku →: 90d
routingroutingDomains: jeder Eintrag zeigt auf eine App (target, bei mehreren Apps mit app), einen Container oder leitet weiter (redirect)Mehr in der Doku →:    - domainsrouting[0].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - www.acme.at          - www.acme.de      approuting[0].appName einer App aus apps; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: backend      targetrouting[0].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: prod    - domainsrouting[1].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - stage.acme.at      approuting[1].appName einer App aus apps; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: backend      targetrouting[1].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: stage    - domainsrouting[2].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - shop.acme.at      approuting[2].appName einer App aus apps; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: shop      targetrouting[2].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: prod    - domainsrouting[3].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - shop.stage.acme.at      approuting[3].appName einer App aus apps; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: shop      targetrouting[3].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: stage    - domainsrouting[4].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - start.acme.at      approuting[4].appName einer App aus apps; nur nötig, wenn es mehr als eine App gibtMehr in der Doku →: landing      targetrouting[4].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: prod    - domainsrouting[5].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - www.acme.at/search      containerrouting[5].containerName eines Containers aus containersMehr in der Doku →: solr    - domainsrouting[6].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - api.acme.at      containerrouting[6].containerName eines Containers aus containersMehr in der Doku →: legacy-api      targetrouting[6].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: prod      portrouting[6].portPort des Containers, falls nicht der aus containersMehr in der Doku →: 8080    - domainsrouting[7].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - mail.stage.acme.at      containerrouting[7].containerName eines Containers aus containersMehr in der Doku →: mailpit      targetrouting[7].targetGenau ein Verzeichnis, z.B. prod. Bei Apps: die App an diesem Fundort bekommt die Domains. Bei container: die Instanz des Containers an diesem Fundort (Pflicht, wenn der Container nicht shared ist).Mehr in der Doku →: stage    - domainsrouting[8].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - acme.at          - acme.de      redirectrouting[8].redirectWeiterleitung auf diese URL; {domain} und {domain-without-www} werden ersetztMehr in der Doku →: https://www.{domain}    - domainsrouting[9].domainsDomains, optional mit Pfad (www.acme.at/search)Mehr in der Doku →:          - www.acme-online.at      redirectrouting[9].redirectWeiterleitung auf diese URL; {domain} und {domain-without-www} werden ersetztMehr in der Doku →: https://{domain-without-www}

Änderungen am Format

Datum Änderung
2026-11 Version 1

Neue, optionale Felder kommen in Version 1 dazu. Inkompatible Änderungen bekommen eine neue Version mit eigener Doku; diese Seite bleibt erhalten.