# Lokal entwickeln Im geklonten Workspace startest du jede Anwendung mit ap run-local, nutzt die Runtimes aus .tool-versions und hältst dich an die Regeln für generierte und eigene Dateien, die auch für KI-Agenten gelten. > Source: https://www.application-platform.com/de/docs/local-development/ Ein geklontes Projekt liegt unter `~/Documents/application-platform///` mit einem Ordner pro Repository; Symlinks auf `local-configuration` legen `AGENTS.md`, `CLAUDE.md`, `.cursor`, `.claude`, `.codex` und `.vscode` daneben. Öffne im Editor den Projektordner statt eines einzelnen Repositories; im [Remote-Workspace]({{< relref "workspaces-overview" >}}) ist das Layout identisch. ## Anwendungen starten Jede Anwendung startet im Root ihres Repositories mit demselben Befehl: ```bash ap run-local ``` Ein Backend startet Docker-Dienste und Dev-Server, eine App Flutter Web oder den Dev-Server ihres Stacks, eine Homepage Hugo oder Astro, jeweils mit den Env-Dateien und auf festen Ports (`ap ports`). Bei Flutter gibst du Ziel und Gerät an, etwa `ap run-local chrome`; `--env dev` lädt die Dev-Konfiguration statt der lokalen, und der Start-Button der Plattform-Extension führt denselben Befehl aus, siehe [Anwendungen starten]({{< relref "workspace-ubuntu-dev-scripts" >}}). ## Runtimes über asdf Die Runtime-Versionen stehen pro Repository in `.tool-versions`; `asdf` verwaltet sie auf macOS und Linux, auf Windows FVM, NVM und HVM. `ap bootstrap` installiert sie ohne Start der Anwendung, `ap doctor` zeigt fehlende Werkzeuge. Installiere Runtimes nicht global am Projekt vorbei, sonst baut deine Maschine anders als die Pipeline. ## Generierte und eigene Dateien Die Plattform schreibt `env/*.generated.env` und `.gitlab-ci.yml` und überschreibt sie bei Änderungen am Projekt; deine Werte kommen in `env/*.custom.env`, danach startest du `ap run-local` neu. Ein Pre-Commit-Hook (`ap git pre-commit check`) aus Setup-App und `clone` blockiert Commits an den generierten Dateien; die Dateien im Einzelnen und `gitops-configuration` für Dev und Prod stehen unter [Umgebungsvariablen]({{< relref "environment-setup" >}}). Passwörter, Tokens und Schlüssel verwaltet die Plattform verschlüsselt; sie gehören nicht in `*.custom.env`, Commits, Logs oder Chat-Antworten. ## Uploads im Backend Persistente Datei-Uploads speichert ein Backend lokal unter `./upload` und im Container unter `/app/upload`, wohin der Server `./backend-uploads` mountet; Multer, FastAPI-Upload-Handler oder Laravel Storage zeigen dorthin und nicht auf `user-uploads` oder `/app/uploads`. Dockerfiles legen den Ordner mit `RUN mkdir -p upload` an. ## AGENTS.md als Vertrag Die `AGENTS.md` aus `local-configuration` fasst diese Regeln zusammen und verlangt, im passenden App-Repository statt in `local-configuration` zu arbeiten; alle Agenten lesen sie automatisch. Eigene Regeln ergänzst du dort ([Eigene Regeln für KI-Agenten]({{< relref "ai-instructions" >}})); was die Pipeline nach dem Push macht, steht unter [Git-Workflow und Deployment]({{< relref "git-workflow" >}}).