diff --git a/_locales/de/_meta.ts b/_locales/de/_meta.ts new file mode 100644 index 0000000..cf9a10f --- /dev/null +++ b/_locales/de/_meta.ts @@ -0,0 +1,18 @@ +export default { + index: "Einführung", + 'getting-started': "App-Schnellstart", + studio: "Lizard Studio", + 'framework-guides': "Framework-Anleitungen", + guides: "Anleitungen", + platform: "Limits & Betrieb", + concepts: "Grundkonzepte", + deploy: "Bereitstellung", + variables: "Variablen", + networking: "Netzwerk", + addons: "Managed Addons", + sandboxes: "Sandboxes", + observability: "Observability", + cli: "CLI-Referenz", + dashboard: "App-Dashboard", + agents: "Coding Agents", +}; diff --git a/_locales/de/addons/_meta.ts b/_locales/de/addons/_meta.ts new file mode 100644 index 0000000..18a114f --- /dev/null +++ b/_locales/de/addons/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Überblick", + postgres: "Postgres", + redis: "Redis", + storage: "Object Storage (S3)", +}; diff --git a/_locales/de/addons/index.mdx b/_locales/de/addons/index.mdx new file mode 100644 index 0000000..04cd30d --- /dev/null +++ b/_locales/de/addons/index.mdx @@ -0,0 +1,80 @@ +--- +description: "Stellen Sie verwaltetes Postgres, Redis und S3-kompatiblen Speicher mit einem einzigen lizard add-Befehl bereit und binden Sie sie dann per Referenz in Services ein." +--- + + + +# Verwaltete Addons + +Lizard stellt verwaltetes **Postgres**, **Redis** und **S3-kompatiblen Objektspeicher** mit einem einzigen Befehl bereit. Jedes Add-on befindet sich in Ihrem Projekt, stellt einen festen Satz von Umgebungsvariablen bereit und wird von Ihren Services über [Referenzen](/concepts/architecture#cross-resource-references) verwendet. + + + +## Ein Add-on bereitstellen + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +## Benennung + +Das **erste** Add-on eines bestimmten Typs erhält den bloßen Typ als Namen — daher funktioniert `${{postgres.DATABASE_URL}}` sofort. Zusätzliche Addons desselben Typs erhalten einen generierten Namen wie `postgres-autumn-bear`. + +Es gibt keinen Fallback über einen Typ-Alias: Eine Referenz muss den **tatsächlichen** Namen des Addons verwenden. Da Referenzen per ID gespeichert werden, können Sie ein Add-on später umbenennen, ohne bestehende Verbraucher zu beeinträchtigen: + +```bash +lizard service rename --service postgres # addons rename through the same command +``` + + + +## Ein Add-on verwenden + +Referenzieren Sie die Variablen eines Addons aus jedem Service. Die Referenz wird beim Bereitstellen aufgelöst und automatisch rotiert, wenn sich die Zugangsdaten des Addons ändern: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +Beschränken Sie die Referenz auf die Services, die sie tatsächlich verwenden (siehe [Secret-Scoping](/variables#scoping)). + + + +## Variablen nach Typ + +| Add-on | Variablen | +|-------|-----------| +| **postgres** | `DATABASE_URL`, `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`, `POSTGRES_USER`, `POSTGRES_DB`, `POSTGRES_PASSWORD` | +| **redis** | `REDIS_URL` | +| **s3** | `S3_ENDPOINT`, `S3_DEFAULT_BUCKET`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `S3_REGION` | + + + +## Browser im Dashboard + +Das [Dashboard](/dashboard) enthält einen Datenbrowser für jedes Add-on — einen SQL-/Tabellen-Editor für Postgres, einen Key-Browser für Redis und einen Bucket-/Objekt-Browser für S3 — sodass Sie Daten prüfen und bearbeiten können, ohne Lizard zu verlassen. + + + +## Speicher + +Daten-Volumes von Addons sind **nur erweiterbar**. Erhöhen Sie die Kapazität mit: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Anleitungen nach Typ + +- [Postgres](/addons/postgres) +- [Redis](/addons/redis) +- [Object Storage (S3)](/addons/storage) + +Warum ein Prototyp in der Regel alle drei gleichzeitig braucht, erfahren Sie unter [dem Rest des Stacks, den ein SaaS braucht](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#the-rest-of-the-stack-a-saas-needs). diff --git a/_locales/de/addons/postgres.mdx b/_locales/de/addons/postgres.mdx new file mode 100644 index 0000000..72d6fa2 --- /dev/null +++ b/_locales/de/addons/postgres.mdx @@ -0,0 +1,107 @@ +--- +description: "Stellen Sie auf Lizard eine verwaltete PostgreSQL-Datenbank bereit, verbinden Sie sie per Referenz mit einem Service, führen Sie Migrationen beim Bereitstellen aus und erweitern Sie ihren Speicher." +--- + +# Managed Postgres + +Eine verwaltete PostgreSQL-Datenbank, mit einem einzigen Befehl bereitgestellt und per Referenz mit Ihren Services verbunden. + + + +## Bereitstellen + +```bash +lizard add postgres +``` + +Das erste Postgres-Add-on heißt `postgres`, daher funktioniert `${{postgres.DATABASE_URL}}` sofort. + + + +## Umgebungsvariablen + +Das Add-on stellt einen Standardsatz an Verbindungsvariablen bereit: + +| Variable | Beschreibung | +|----------|-------------| +| `DATABASE_URL` | Vollständige Verbindungszeichenfolge (`postgres://…`) | +| `PGHOST` | Host | +| `PGPORT` | Port | +| `PGUSER` | Benutzer | +| `PGPASSWORD` | Passwort | +| `PGDATABASE` | Datenbankname | +| `POSTGRES_USER` | Alias für den Benutzer | +| `POSTGRES_DB` | Alias für die Datenbank | +| `POSTGRES_PASSWORD` | Alias für das Passwort | + + + +## Einen Service verbinden + +Referenzieren Sie die Verbindungszeichenfolge aus dem konsumierenden Service und deployen Sie erneut: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +Die Referenz wird zur Bereitstellen-Zeit aufgelöst und automatisch rotiert, wenn sich die Zugangsdaten des Addons ändern — jeder konsumierende Service übernimmt den neuen Wert beim nächsten Bereitstellen. + +Prüfen Sie die Verbindung, ohne die Verbindungszeichenfolge auszugeben: + +```bash +lizard run --service api -- sh -c 'psql "$DATABASE_URL" -c "SELECT 1"' +``` + + + +## Migrationen beim Bereitstellen ausführen + +Verwenden Sie für Migrationen einen Pre-Bereitstellen-Befehl. Gestalten Sie Migrationen so, dass sie sicher erneut ausgeführt werden können und sowohl mit der alten als auch mit der neuen Anwendungsversion kompatibel sind: + +```bash +lizard service set api --set preDeployCommand="npm run migrate" +lizard redeploy --service api +``` + +Für eine Django-App lautet der Befehl `python manage.py migrate`; [Python-App-Hosting](https://lizard.build/blog/python-app-hosting#deploying-django) enthält das entsprechende Pendant für Flask und FastAPI. + + + +## Daten durchsuchen und abfragen + +Öffnen Sie den **Postgres-Editor** im Dashboard (`lizard open`), um SQL auszuführen und Tabellen direkt zu durchsuchen. Für lokale Ad-hoc-Arbeiten führen Sie einen Befehl mit der in den Service injizierten Umgebung aus: + +```bash +lizard run --service api -- sh -c 'exec psql "$DATABASE_URL"' +``` + + + +## Speicher erweitern + +Datenvolumes können nur vergrößert werden: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Mehrere Datenbanken + +Wenn Sie ein zweites Postgres hinzufügen, erhält es einen generierten Namen (z. B. `postgres-autumn-bear`). Referenzieren Sie es explizit: + +```bash +lizard add postgres +lizard secrets set ANALYTICS_URL='${{postgres-autumn-bear.DATABASE_URL}}' --service api +``` + + + +## Siehe auch + +- [Managed Addons](/addons) — Benennung, Referenzen und die Dashboard-Browser. +- [Service-übergreifende Referenzen](/variables/references) — Referenzsyntax und Auflösung. + +Siehe [Speicher und Wiederherstellung](/platform/storage-and-recovery) für die Planung von Backup und Wiederherstellung. Lokal `lizard run` erfordert `psql` und einen erreichbaren Datenbank-Endpunkt; es läuft nicht innerhalb des deployten Service. diff --git a/_locales/de/addons/redis.mdx b/_locales/de/addons/redis.mdx new file mode 100644 index 0000000..7f70e8c --- /dev/null +++ b/_locales/de/addons/redis.mdx @@ -0,0 +1,79 @@ +--- +description: "Fügen Sie eine Managed Redis-Instanz für Caching, Warteschlangen, Rate Limiting und Pub/Sub hinzu und verbinden Sie sie mit einem einzigen Verweis mit einem Service." +--- + +# Managed Redis + +Eine Managed Redis-Instanz für Caching, Warteschlangen, Rate Limiting und Pub/Sub. + + + +## Bereitstellen + +```bash +lizard add redis +``` + +Das erste Redis-Add-on heißt `redis`, daher funktioniert `${{redis.REDIS_URL}}` sofort. + + + +## Umgebungsvariablen + +| Variable | Beschreibung | +|----------|-------------| +| `REDIS_URL` | Vollständige Verbindungszeichenfolge (`redis://…`) | + + + +## Einen Service verbinden + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard redeploy --service api +``` + +Der Verweis wird beim Bereitstellen aufgelöst und mit den Zugangsdaten des Addons rotiert. + + + +## Häufige Anwendungsfälle + +- **Cache** — speichert berechnete Ergebnisse anhand der Anfrage. +- **Warteschlange / Worker** — kombinieren Sie Redis mit einem [Service im Worker-Modus](/deploy/workers), der Jobs verarbeitet. +- **Rate Limiting / Sitzungen** — schneller gemeinsam genutzter Status über [Replikate](/deploy/scaling) hinweg. + +```bash +# A worker that drains a Redis queue +lizard add -r your-org/worker -n jobs +lizard service set jobs --set containerPort=0 +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service jobs +lizard redeploy --service jobs +``` + + + +## Schlüssel durchsuchen + +Öffnen Sie den **Redis-Browser** im Dashboard (`lizard open`), um Schlüssel und Werte zu prüfen. Für lokalen Zugriff: + +```bash +lizard run --service api -- sh -c 'exec redis-cli -u "$REDIS_URL"' +``` + + + +## Speicher erweitern + +```bash +lizard scale --service redis --storage 4096 +``` + + + +## Siehe auch + +- [Managed Addons](/addons) — Benennung, Verweise und die Browser im Dashboard. +- [Background Workers](/deploy/workers) — Redis mit einem Worker kombinieren, der eine Warteschlange verarbeitet. + +`lizard run` startet den Befehl lokal mit der ausgewählten Service-Umgebung. Installieren Sie `redis-cli` lokal und prüfen Sie, dass der Endpunkt erreichbar ist. diff --git a/_locales/de/addons/storage.mdx b/_locales/de/addons/storage.mdx new file mode 100644 index 0000000..4f999cd --- /dev/null +++ b/_locales/de/addons/storage.mdx @@ -0,0 +1,108 @@ +--- +description: "S3-kompatibler Objektspeicher für Uploads, Assets und Backups. Erhalten Sie einen öffentlich lesbaren Bucket und Verbindungsvariablen mit einem einzigen lizard add s3." +--- + +# Object Storage (S3) + +S3-kompatibler Objektspeicher für Uploads, Assets und Backups. Die Bereitstellung eines `s3`-Add-ons erstellt außerdem einen **öffentlich lesbaren Bucket namens `default`**, sodass Sie Dateien ohne zusätzlichen Einrichtungsaufwand bereitstellen können. + + + +## Bereitstellen + +```bash +lizard add s3 +``` + +Das erste S3-Add-on heißt `s3`, daher funktionieren `${{s3.S3_ENDPOINT}}` und ähnliche sofort. + + + +## Umgebungsvariablen + +| Variable | Beschreibung | +|----------|-------------| +| `S3_ENDPOINT` | S3-kompatible Endpoint-URL | +| `S3_DEFAULT_BUCKET` | Der automatisch erstellte Bucket-Name (`default`) | +| `S3_ACCESS_KEY_ID` | Access Key | +| `S3_SECRET_ACCESS_KEY` | Secret Key | +| `S3_REGION` | Region | + + + +## Einen Service verbinden + +```bash +lizard secrets set \ + S3_ENDPOINT='${{s3.S3_ENDPOINT}}' \ + S3_DEFAULT_BUCKET='${{s3.S3_DEFAULT_BUCKET}}' \ + S3_ACCESS_KEY_ID='${{s3.S3_ACCESS_KEY_ID}}' \ + S3_SECRET_ACCESS_KEY='${{s3.S3_SECRET_ACCESS_KEY}}' \ + S3_REGION='${{s3.S3_REGION}}' \ + --service api +lizard redeploy --service api +``` + + + +## Verwendung mit einem AWS SDK + +Der Endpoint ist S3-kompatibel. Setzen Sie **path-style**-Adressierung: + +```ts +import { S3Client } from "@aws-sdk/client-s3"; + +const s3 = new S3Client({ + endpoint: process.env.S3_ENDPOINT, + region: process.env.S3_REGION, + forcePathStyle: true, // required + credentials: { + accessKeyId: process.env.S3_ACCESS_KEY_ID!, + secretAccessKey: process.env.S3_SECRET_ACCESS_KEY!, + }, +}); +``` + + + +## Öffentliche Dateien + +Objekte in jedem **öffentlichen** Bucket werden ohne Authentifizierung auf zwei Arten bereitgestellt: + +1. **Gateway-URL** (im Dashboard angezeigt): + ``` + https://s3-.onlizard.com/// + ``` +2. **Plattform-Proxy** (der Dashboard-Host, mit langlebigen unveränderlichen Cache-Headern): + ``` + /api/s3//public// + ``` + +Alles, was in den Bucket `default` hochgeladen wird, ist sofort öffentlich verfügbar unter: + +``` +/api/s3//public/default/ +``` + + + +## Objekte durchsuchen + +Öffnen Sie den **S3-Browser** im Dashboard (`lizard open`), um Objekte und Buckets hochzuladen, herunterzuladen und zu verwalten. + +> **Bucket-ACL-Änderungen** (einen Bucket öffentlich/privat machen) sind in der CLI noch nicht verfügbar — verwalten Sie sie im Dashboard. + + + +## Speicher erweitern + +```bash +lizard scale --service s3 --storage 16384 +``` + + + +## Siehe auch + +- [Managed Addons](/addons) — Benennung, Referenzen und die Dashboard-Browser. +- [Service-übergreifende Referenzen](/variables/references) — Referenzsyntax und Auflösung. diff --git a/_locales/de/agents.mdx b/_locales/de/agents.mdx new file mode 100644 index 0000000..326e238 --- /dev/null +++ b/_locales/de/agents.mdx @@ -0,0 +1,90 @@ +--- +description: "Steuere Lizard über einen KI-Coding-Agenten: Lies Lizard Skill, ermittle Befehlsschemata mit --json und deploye über Lizard CLI." +--- + +# Coding-Agents + +Lizard ist so konzipiert, dass es sich von KI-Coding-Agents genauso einfach steuern lässt wie von Menschen. Die CLI enthält ein **eingebettetes Skill**, das einem Agenten die gesamte Plattform vermittelt, und jeder Befehl ist über `--json` **selbstbeschreibend**, sodass Agents nie raten müssen. + + + +## Das eingebettete Skill + +Die maßgebliche Nutzungsanleitung befindet sich in der CLI und ist mit ihr versioniert, sodass sie immer zur installierten Version passt. Ein Agent liest sie mit: + +```bash +lizard skills get core --json +``` + +Dies gibt `{ name, frontmatter, content, … }` zurück — `content` ist die vollständige Anleitung (Build-Pipeline, env-Priorität, Add-ons, Discovery, Exit-Codes). Zugehörige Unterbefehle: + +```bash +lizard skills list # available embedded skills +lizard skills get core # the core guide +lizard skills path # where skills are stored +``` + +Da die Anleitung mit dem Binary gebündelt ist, aktualisiert `lizard upgrade` auch die Anweisungen des Agenten. + + + +## Selbstbeschreibende Befehle + +Agents ermitteln die exakten Flag-Formen zur Laufzeit, statt sich auf auswendig gelernte Syntax zu verlassen: + +```bash +lizard --help --json # full command tree + exit codes +lizard --help --json # a specific command's schema +``` + +Siehe [JSON & Automatisierung](/cli/json). + + + +## Bootstrapping in einem Agenten + +Ein typischer Agent-Ablauf: + +1. **Anleitung laden:** `lizard skills get core --json` → `content` lesen. +2. **Authentifizierung optimistisch prüfen:** Führe die Aufgabe des Nutzers aus; bei Exit-Code `2` führe `lizard login` aus, gib die ausgegebene URL an den Nutzer weiter und versuche es dann erneut. +3. **Kontext vor Änderungen auflösen:** `lizard status` (cwd-Link) und `lizard ps --json` (Services). +4. **Handeln** mithilfe der Anleitung — `add`, `up`, `secrets`, `domain` usw., immer mit `--json`. + +Wenn das Binary `lizard` nicht vorhanden ist, installiere es zuerst: + +```bash +npm install -g @lizard-build/cli +``` + + + +## Konventionen, denen Agents folgen sollten + +- **Übergib bei nicht interaktiven Aufrufen immer `--json`**. +- **Bestätige destruktive Aktionen** (Service löschen, Add-on entfernen, ein projektweites Secret überschreiben, Prod-Neustart) mit dem Nutzer — die eigenen Prompts der CLI werden nur in einer TTY ausgelöst. +- **Beschränke Secrets standardmäßig auf den Service, der sie verwendet**; reserviere `--global` für nachweislich öffentliche Werte. Siehe [Variablen & Secrets](/variables#scoping). +- **Schreibe Dockerfiles nicht ungefragt** — lizardpack erkennt die meisten Stacks automatisch. Versuche zuerst ein Deployment. Siehe [Build-Pipeline](/concepts/build-pipeline). +- **Verwende `lizard up` nicht, um einen git-basierten Service auf Upload umzustellen** — verwende `service set` + `redeploy`. + + + +## Editor-Integrationen + +Lizard Skill wird als öffentliches Bootstrap verteilt, damit Agents in Editoren und Assistenten es bei Bedarf installieren und laden und dann dieselbe CLI steuern können, die in dieser Dokumentation beschrieben wird. Die CLI ist die einzige verlässliche Quelle — es gibt keine separate Agent-API, die man lernen muss. + +Das gilt auch für KI-IDEs: Sie schreiben und testen eine App, hosten sie aber nicht. Siehe [Deployment einer in Google Antigravity gebauten App](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command), wo das gesamte Deployment mit zwei Prompts ausgeführt wird. + + + +## Siehe auch + +- [`lizard skills`](/cli/skills) — die vollständige Befehlsreferenz. +- [JSON & Automatisierung](/cli/json) — Ausgabe von `--json` und Schema-Discovery. +- [Variablen & Secrets](/variables#scoping) — Konventionen zur Secret-Begrenzung, denen Agents folgen sollten. +- [Deploye deine App aus Claude Code](https://lizard.build/blog/deploy-from-claude-code#deploy-from-claude-code-in-3-steps) — dasselbe Bootstrap als Walkthrough, mit den Prompts, die es steuern. + + + +## Eigenen MCP-Server hosten + +Ein Agent, der Lizard CLI verwendet, und eine Anwendung, die MCP bereitstellt, sind getrennte Workflows. Die oben genannten CLI-Befehle stellen keinen MCP-Transport bereit. Um deinen eigenen Server mit Streamable HTTP zu deployen, folge der [Remote-MCP-Anleitung](/guides/deploy-mcp-server). diff --git a/_locales/de/cli/_meta.ts b/_locales/de/cli/_meta.ts new file mode 100644 index 0000000..c6332e6 --- /dev/null +++ b/_locales/de/cli/_meta.ts @@ -0,0 +1,46 @@ +export default { + index: "Übersicht", + json: "JSON & Automatisierung", + '-- auth': { type: "separator", title: "Authentifizierung & Konto" }, + login: "login", + logout: "logout", + whoami: "whoami", + workspace: "workspace", + '-- projects': { type: "separator", title: "Projekte & Verknüpfung" }, + init: "init", + link: "link", + unlink: "unlink", + status: "status", + project: "project", + config: "config", + '-- create': { type: "separator", title: "Dienste & Add-ons erstellen" }, + add: "add", + '-- deploy': { type: "separator", title: "Deployment" }, + up: "up", + redeploy: "redeploy", + restart: "restart", + '-- svc': { type: "separator", title: "Dienstkonfiguration" }, + service: "service", + port: "port", + scale: "scale", + '-- secrets': { type: "separator", title: "Secrets" }, + secrets: "secrets", + '-- domains': { type: "separator", title: "Domains" }, + domain: "domain", + '-- observability': { type: "separator", title: "Logs, Metriken & Ereignisse" }, + logs: "logs", + metrics: "metrics", + events: "events", + ps: "ps", + '-- running': { type: "separator", title: "Befehle ausführen" }, + run: "run", + ssh: "ssh", + '-- github': { type: "separator", title: "GitHub" }, + git: "git", + '-- misc': { type: "separator", title: "Verschiedenes" }, + regions: "regions", + open: "open", + docs: "docs", + upgrade: "upgrade", + skills: "skills", +}; diff --git a/_locales/de/cli/add.mdx b/_locales/de/cli/add.mdx new file mode 100644 index 0000000..820b734 --- /dev/null +++ b/_locales/de/cli/add.mdx @@ -0,0 +1,76 @@ +--- +description: "lizard add erstellt einen Service aus einem GitHub-Repo, einem leeren Service oder einem verwalteten Add-on. Vollständige Flag-Referenz mit praxisnahen Beispielen." +--- + +# lizard add + +Füge dem Projekt eine Datenbank, einen Service oder ein Repo hinzu. + + + +## Verwendung + +```bash +lizard add [types...] [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-r, --repo ` | Einen Service aus einem GitHub-Repo erstellen | +| `-s, --service ` | Einen leeren Service erstellen | +| `-a, --addon ` | Verwaltete Add-ons hinzufügen (`postgres` / `redis` / `s3`) | +| `-n, --name ` | Name für `${{name.KEY}}`-Referenzen | +| `-v, --variables ` | Eine Umgebungsvariable vorbelegen (wiederholbar) | +| `--region ` | Region für die Bereitstellung | +| `--no-deploy` | Repo verknüpfen, aber den ersten Build überspringen | +| `--list` | Verfügbare Datenbanktypen anzeigen | + + + +## Beispiele + + + +### Einen Service aus einem GitHub-Repo erstellen + +```bash +lizard add -r your-org/your-app +``` + +Dadurch wird ein Service aus `github`-Quelle erstellt, das Repo geklont, der Stack automatisch erkannt, gebaut und eine Live-URL zurückgegeben. + + + +### Add-ons bereitstellen + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +### Einen leeren Service erstellen + +```bash +lizard add -s worker +``` + + + +### Einen Service benennen und Variablen vorbelegen + +```bash +lizard add -r your-org/monorepo -n api +``` + + + +## Siehe auch + +- [Von GitHub deployen](/deploy/github) — Repos verbinden, privater Zugriff und automatische Neu-Bereitstellungen bei Push +- [Managed Addons](/addons) — Bereitstellung, Benennung und Verwendung von postgres/redis/s3 +- [lizard up](/cli/up) — das aktuelle Verzeichnis hochladen und deployen, statt ein Repo zu verknüpfen diff --git a/_locales/de/cli/config.mdx b/_locales/de/cli/config.mdx new file mode 100644 index 0000000..dd3c9eb --- /dev/null +++ b/_locales/de/cli/config.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard config apply überträgt eine lizard-config.json-Datei in Ihr Projekt, mit einem --dry-run-Flag, um die Änderungen zuerst in der Vorschau anzuzeigen." +--- + +# lizard config + +Eine `lizard-config.json`-Datei auf das Projekt anwenden. + + + +## Verwendung + +```bash +lizard config apply [flags] +``` + + + +## Unterbefehle + +### `lizard config apply` + +Eine `lizard-config.json`-Datei auf das Projekt anwenden. + +| Flag | Beschreibung | +|------|-------------| +| `-f, --file ` | Konfigurationsdatei (Standard: `lizard-config.json`) | +| `--dry-run` | Zeigt, was sich ändern würde, ohne die Änderungen anzuwenden | + + + +## Beispiele + + + +### Die Standard-Konfigurationsdatei anwenden + +```bash +lizard config apply +``` + + + +### Eine Konfigurationsdatei aus einem benutzerdefinierten Pfad anwenden + +```bash +lizard config apply -f ./configs/prod.json +``` + + + +### Änderungen in der Vorschau anzeigen, ohne sie anzuwenden + +```bash +lizard config apply --dry-run +``` + + + +## Siehe auch + +- [lizard service](/cli/service) — einzelne Services verwalten +- [Architecture](/concepts/architecture) — wie Workspaces, Projekte und Services zusammenhängen diff --git a/_locales/de/cli/docs.mdx b/_locales/de/cli/docs.mdx new file mode 100644 index 0000000..168015b --- /dev/null +++ b/_locales/de/cli/docs.mdx @@ -0,0 +1,33 @@ +--- +description: "lizard docs öffnet die Lizard-Dokumentation direkt aus dem Terminal in deinem Standardbrowser. Verwendung und Beispiele." +--- + +# lizard docs + +Öffne die Dokumentation im Browser. + + + +## Verwendung + +```bash +lizard docs +``` + + + +## Beispiele + + + +### Die Dokumentationswebsite öffnen + +```bash +lizard docs +``` + + + +## Siehe auch + +- [CLI-Referenz](/cli) — Installation, globale Flags und Exit-Codes diff --git a/_locales/de/cli/domain.mdx b/_locales/de/cli/domain.mdx new file mode 100644 index 0000000..b3a8250 --- /dev/null +++ b/_locales/de/cli/domain.mdx @@ -0,0 +1,102 @@ +--- +description: "lizard domain zeigt die Domain eines Dienstes, erzeugt eine onlizard.com-Subdomain oder hängt einen benutzerdefinierten Hostnamen an und verifiziert ihn mit automatischem TLS." +--- + +# lizard domain + +Zeigt die aktuelle Domain an oder hängt eine benutzerdefinierte an. + + + +## Verwendung + +```bash +lizard domain [hostname] [flags] +``` + +Der Hostname ist ein Positionsargument — es gibt kein Subcommand `add`. Wenn du `lizard domain` ohne Argumente ausführst, wird die aktuelle Domain des Dienstes angezeigt. + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-s, --service ` | Dienst | +| `--port ` | Freizugebender Port | + + + +## Unterbefehle + +### `lizard domain generate` + +Erzeugt eine neue `*.onlizard.com`-Subdomain. + +### `lizard domain verify ` + +Prüft den TXT-Record und aktiviert die Domain. TLS wird automatisch bereitgestellt. + +### `lizard domain delete ` + +Entfernt eine Domain (Alias `rm`). + +| Flag | Beschreibung | +|------|-------------| +| `-y, --yes` | Bestätigung überspringen | + + + +## Beispiele + + + +### Aktuelle Domain anzeigen + +```bash +lizard domain +``` + + + +### Eine Subdomain erzeugen + +```bash +lizard domain generate +``` + + + +### Eine benutzerdefinierte Domain anhängen + +```bash +lizard domain app.example.com --service web +``` + +Lizard gibt die zu erstellenden DNS-Records zurück (einen `CNAME` für den Hostnamen und einen `TXT`-Record zur Verifizierung). Füge sie bei deinem DNS-Anbieter hinzu und verifiziere dann: + +```bash +lizard domain verify app.example.com +``` + + + +### Eine Domain an einen bestimmten Port anhängen + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +### Eine Domain entfernen + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes +``` + + + +## Siehe auch + +- [Networking](/networking) — erzeugte Domains, TLS und Worker-Dienste +- [In Regionen bereitstellen](/deploy/regions) — Regionsauswahl für Dienste diff --git a/_locales/de/cli/events.mdx b/_locales/de/cli/events.mdx new file mode 100644 index 0000000..aa8d998 --- /dev/null +++ b/_locales/de/cli/events.mdx @@ -0,0 +1,58 @@ +--- +description: "lizard events gibt den Bereitstellen-Verlauf eines Service und den aktuellen Replikat-Status aus, mit Flags zum Begrenzen der Einträge oder zum Auswählen eines einzelnen Service." +--- + +# lizard events + +Bereitstellen-Verlauf und Replikat-Status anzeigen. + + + +## Verwendung + +```bash +lizard events [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-n, --limit ` | Anzahl der anzuzeigenden Einträge (Standard: 10) | +| `-s, --service ` | Ereignisse für einen bestimmten Service anzeigen | + + + +## Beispiele + + + +### Bereitstellen-Verlauf und Replikat-Status anzeigen + +```bash +lizard events +``` + + + +### Ereignisse für einen bestimmten Service anzeigen + +```bash +lizard events --service api +``` + + + +### Mehr Einträge anzeigen + +```bash +lizard events --limit 25 +``` + + + +## Siehe auch + +- [Events & History](/observability/events) — was die einzelnen Einträge enthalten und wie sie der Bereitstellungen-Ansicht im Dashboard entsprechen +- [lizard ps](/cli/ps) — eine schnelle Übersicht über den Status und die URL aller Services +- [Bereitstellungen](/concepts/deployments) — der Bereitstellen-Lebenszyklus diff --git a/_locales/de/cli/git.mdx b/_locales/de/cli/git.mdx new file mode 100644 index 0000000..d30dbf1 --- /dev/null +++ b/_locales/de/cli/git.mdx @@ -0,0 +1,80 @@ +--- +description: "lizard git verbindet die GitHub App, meldet den Repository-Status und wechselt einen Service mit einer erneuten Bereitstellung auf einen anderen Branch." +--- + +# lizard git + +Verwalte die GitHub-Verbindung für das verknüpfte Projekt und seine Services. + + + +## Verwendung + +```bash +lizard git connect +lizard git status +lizard git checkout [flags] +``` + + + +## Unterbefehle + +### `lizard git connect` + +Verbinde die GitHub App, um auf private Repositories zuzugreifen. + +### `lizard git status` + +Zeige die GitHub-Verbindung und den Repository-Status an. + +### `lizard git checkout ` + +Wechsle einen Service auf einen anderen Branch und stelle ihn erneut bereit. + +| Flag | Beschreibung | +|------|-------------| +| `--detach` | Log-Streaming überspringen | + + + +## Beispiele + + + +### GitHub App verbinden + +```bash +lizard git connect +``` + + + +### Verbindungs- und Repository-Status prüfen + +```bash +lizard git status +``` + + + +### Einen Service auf einen anderen Branch umstellen + +```bash +lizard git checkout api staging +``` + + + +### Branches wechseln, ohne Logs zu streamen + +```bash +lizard git checkout api staging --detach +``` + + + +## Siehe auch + +- [Von GitHub bereitstellen](/deploy/github) — ein Repository verbinden, automatische erneute Bereitstellung bei Push und Monorepo-Einrichtung +- [lizard add](/cli/add) — einen Service aus einem GitHub-Repository erstellen diff --git a/_locales/de/cli/index.mdx b/_locales/de/cli/index.mdx new file mode 100644 index 0000000..d360b3b --- /dev/null +++ b/_locales/de/cli/index.mdx @@ -0,0 +1,86 @@ +--- +description: "Installiere und aktualisiere die lizard CLI, authentifiziere dich und schlage globale Flags, Exit-Codes und die Laufzeit-Schema-Erkennung für jeden Befehl nach." +--- + + + +# CLI-Referenz + +Die `lizard` CLI ist die primäre Schnittstelle zur Plattform. Diese Seite behandelt Installation, globale Flags, Exit-Codes und Laufzeit-Erkennung. Jeder Befehl hat seine eigene Referenzseite in der Seitenleiste — siehe [`lizard up`](/cli/up), [`lizard service`](/cli/service), [`lizard secrets`](/cli/secrets) und die übrigen. + +> Referenz generiert für CLI **v0.3.62**. Führe `lizard --help --json` aus, um das exakte, versionspassende Schema eines beliebigen Befehls zu sehen. + + + +## Installation & Aktualisierung + +```bash +npm install -g @lizard-build/cli +lizard --version +lizard upgrade # update to the latest version +lizard upgrade --check # check without installing +``` + +Verwende immer die global installierte `lizard`-Binärdatei — **nicht** `npx`. Hinweise zur Behebung von Berechtigungsfehlern findest du unter [Quickstart](/getting-started#1-install-the-cli). + + + +## Authentifizierung + +```bash +lizard login # browser OAuth +lizard login --token lzd_xxx # token auth +lizard logout +lizard whoami # current user, workspace, linked project +``` + +In CI solltest du `LIZARD_TOKEN` in der Umgebung setzen, statt `login` auszuführen. + + + +## Globale Flags + +| Flag | Beschreibung | +|------|-------------| +| `-V, --version` | CLI-Version ausgeben | +| `--json` | Maschinell lesbare Ausgabe. Mit `--help` kombinieren, um das Schema eines Befehls auszugeben | + +Die meisten Befehle akzeptieren außerdem `-p, --project`, `-s, --service` und `-w, --workspace`, um statt der verknüpften Ressource eine bestimmte Ressource anzusteuern. + +## Exit-Codes + +| Code | Bedeutung | Was zu tun ist | +|------|---------|------------| +| `0` | Erfolg | fortfahren | +| `1` | allgemeiner Fehler | Nachricht lesen | +| `2` | Authentifizierung (401/403) | `lizard login` ausführen | +| `3` | nicht gefunden (404) | Namen mit `lizard ps` / `lizard project list` prüfen | +| `4` | Zeitüberschreitung (408/504) | erneut versuchen | +| `5` | vom Benutzer abgebrochen | stoppen | + + + +## Laufzeit-Erkennung + +Die CLI dokumentiert sich selbst. Um den vollständigen Befehlsbaum, globale Flags und Exit-Codes anzuzeigen: + +```bash +lizard --help --json +``` + +Für die exakten Argumente und Optionen eines beliebigen Befehls oder Unterbefehls: + +```bash +lizard --help --json +lizard --help --json # e.g. lizard service set --help --json +``` + +Das entspricht immer deiner installierten Version — ziehe es Vermutungen über Flag-Formen vor. So lernt auch ein Agent die CLI kennen, ohne darauf trainiert worden zu sein: siehe [Deployment aus Claude Code](https://lizard.build/blog/deploy-from-claude-code). + + + +## Konfiguration & Status + +- Die CLI speichert Authentifizierung und die Projektverknüpfung des aktuellen Verzeichnisses in `~/.lizard/config.json`. +- `lizard status` zeigt die Workspace-/Projekt-/Service-Verknüpfung des cwd an (keine Authentifizierung erforderlich). +- `lizard config apply` wendet eine `lizard-config.json`-Datei auf ein Projekt an (verwende `--dry-run` für eine Vorschau). diff --git a/_locales/de/cli/init.mdx b/_locales/de/cli/init.mdx new file mode 100644 index 0000000..022ee75 --- /dev/null +++ b/_locales/de/cli/init.mdx @@ -0,0 +1,64 @@ +--- +description: "lizard init erstellt oder wählt ein Projekt aus und verknüpft es mit dem aktuellen Verzeichnis, einschließlich der expliziten Form, die Sie in CI benötigen." +--- + +# lizard init + +Erstellen oder wählen Sie ein Projekt aus und verknüpfen Sie es mit dem aktuellen Verzeichnis. + + + +## Verwendung + +```bash +lizard init [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-n, --name ` | Projektname (wird erstellt, falls nicht vorhanden) | +| `-w, --workspace ` | Workspace-ID, Slug oder Name | +| `--force` | Erneut verknüpfen, auch wenn bereits verknüpft | + + + +## Beispiele + + + +### Das aktuelle Verzeichnis interaktiv verknüpfen + +```bash +lizard init +``` + + + +### In CI explizit verknüpfen + +`lizard up` führt `init` für Sie in einem TTY aus, aber in einer Nicht-TTY-Umgebung (CI) gibt es einen Fehler aus, statt stillschweigend ein Projekt zu erstellen. Verknüpfen Sie es zuerst explizit: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +### Ein Verzeichnis erneut verknüpfen, das bereits verknüpft ist + +```bash +lizard init --name my-project --force +``` + + + +## Siehe auch + +- [lizard link](/cli/link) — das aktuelle Verzeichnis mit einem vorhandenen Projekt verknüpfen, statt eines zu erstellen +- [lizard status](/cli/status) — den verknüpften Workspace, das Projekt und den Service für das aktuelle Verzeichnis anzeigen +- [lizard up](/cli/up) — das aktuelle Verzeichnis hochladen und bereitstellen +- [Core Konzepte](/concepts/architecture) — Projekte, Services und die Build-Pipeline diff --git a/_locales/de/cli/json.mdx b/_locales/de/cli/json.mdx new file mode 100644 index 0000000..77bf2ec --- /dev/null +++ b/_locales/de/cli/json.mdx @@ -0,0 +1,90 @@ +--- +description: "Skripte die lizard CLI: --json bei jedem Befehl, zeilengetrennte Ereignisse für Streaming-Builds, Schema-Erkennung und Token-Authentifizierung in CI." +--- + + + +# JSON & Automatisierung + +Die CLI ist dafür gemacht, per Skript gesteuert zu werden. Übergebe `--json` für maschinenlesbare Ausgabe, nutze sie in CI mit einem Token und ermittle das Schema jedes Befehls zur Laufzeit. + +Der andere Empfänger dieser Ausgabe ist ein KI-Coding-Agent — [Deployment aus Claude Code](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) zeigt, was er mit dem JSON eines fehlgeschlagenen Builds macht. + + + +## `--json` überall + +Füge `--json` zu jedem Befehl hinzu, um strukturierte Ausgabe zu erhalten. Die CLI schaltet auch automatisch auf JSON um, wenn stdout kein TTY ist. + +```bash +lizard ps --json +lizard secrets list --json +lizard metrics --json +``` + + + +### Streaming-Befehle + +Bei Streaming-Befehlen (`lizard up` ohne `--detach`) gibt `--json` **pro Zeile genau ein JSON-Objekt** aus: + +```json +{ "event": "log", "line": "Step 1/8 : FROM node:20" } +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "running", "url": "https://app.onlizard.com" } +``` + +Der Stream endet mit `done` oder `error` / `failed`. `lizard up` gibt zusätzlich ein abschließendes Ereignis `deployed` / `failed` / `deploying` mit `status` und `url` aus (dies kann `null` sein). + + + +### `logs --json` ist eine Momentaufnahme, kein Stream + +`lizard logs --json` gibt die **letzten 200 Zeilen** zurück (überschreibbar mit `--tail N`, maximal 1000) und beendet sich dann. Warte nicht darauf, wenn du weitere Ausgabe erwartest. Für einen bestimmten Vorfall verwende `--restart latest` oder `--restart `. + + + +## Schema-Erkennung + +Gib die exakten Argumente, Optionen und Exit-Codes eines beliebigen Befehls aus: + +```bash +lizard --help --json # whole tree + global flags + exit codes +lizard service set --help --json # one command +``` + +Die Form der Antwort ist `{ cli, version, command: { arguments, options, subcommands }, globalOptions, exitCodes }`. Da sie aus deiner installierten Binärdatei erzeugt wird, passt sie immer zu deiner Version — ziehe sie fest codierten Flags vor. + + + +## CI / Headless-Nutzung + +Authentifiziere dich mit einem Token und verknüpfe das Projekt explizit (headless `up` erstellt kein Projekt automatisch): + +```bash +# Set LIZARD_TOKEN through your CI secret store. +lizard init --name my-project +lizard up --ci --service api --detach +``` + +Prüfe Exit-Codes, um deine Pipeline zu verzweigen: + +| Code | Bedeutung | +|------|---------| +| `0` | erfolgreich | +| `1` | allgemeiner Fehler | +| `2` | Authentifizierung — Token fehlt/abgelaufen | +| `3` | nicht gefunden | +| `4` | Zeitüberschreitung | +| `5` | abgebrochen | + +```bash +if lizard redeploy --service api --json; then + echo "Deploy succeeded" +else + status=$? + echo "Deploy failed with code $status" >&2 + lizard logs --build --json || true + exit "$status" +fi +``` diff --git a/_locales/de/cli/link.mdx b/_locales/de/cli/link.mdx new file mode 100644 index 0000000..a5f70de --- /dev/null +++ b/_locales/de/cli/link.mdx @@ -0,0 +1,60 @@ +--- +description: "lizard link verknüpft das aktuelle Verzeichnis mit einem bestehenden Projekt und optional mit einem bestimmten Service oder Workspace." +--- + +# lizard link + +Verknüpfen Sie das aktuelle Verzeichnis mit einem bestehenden Projekt (und optional mit einem Service). + + + +## Verwendung + +```bash +lizard link [service] [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-p, --project ` | Projektname, Slug oder ID | +| `-s, --service ` | Zu verknüpfender Service | +| `-w, --workspace ` | Workspace | + + + +## Beispiele + + + +### Mit einem bestehenden Projekt verknüpfen + +```bash +lizard link --project my-project +``` + + + +### Mit einem Projekt und einem bestimmten Service verknüpfen + +```bash +lizard link my-service --project my-project +``` + + + +### Innerhalb eines bestimmten Workspace verknüpfen + +```bash +lizard link --project my-project --workspace my-workspace +``` + + + +## Siehe auch + +- [lizard init](/cli/init) — Projekt erstellen oder auswählen und es in einem Schritt verknüpfen +- [lizard unlink](/cli/unlink) — die Verknüpfung aus dem aktuellen Verzeichnis entfernen +- [lizard status](/cli/status) — den verknüpften Workspace, das Projekt und den Service anzeigen +- [Architecture: Projekt](/concepts/architecture) — wie die Verknüpfung von Verzeichnis zu Projekt funktioniert diff --git a/_locales/de/cli/login.mdx b/_locales/de/cli/login.mdx new file mode 100644 index 0000000..e48d5f2 --- /dev/null +++ b/_locales/de/cli/login.mdx @@ -0,0 +1,61 @@ +--- +description: "lizard login authentifiziert über deinen Browser oder ein API-Token sowie die nicht-interaktive Authentifizierung in CI mit LIZARD_TOKEN." +--- + +# lizard login + +Bei Lizard anmelden. + + + +## Verwendung + +```bash +lizard login [flags] +``` + +Standardmäßig öffnet dies deinen Browser für die Authentifizierung per OAuth und kehrt nach der Bestätigung in dein Terminal zurück. + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `--token ` | Mit einem API-Token authentifizieren | + + + +## Beispiele + + + +### Über den Browser anmelden + +```bash +lizard login +``` + + + +### Mit einem Token anmelden + +```bash +lizard login --token lzd_xxx +``` + + + +### In CI nicht-interaktiv anmelden + +In CI oder anderen nicht-interaktiven Umgebungen setze `LIZARD_TOKEN` als Umgebungsvariable, statt `login` auszuführen: + +```bash +export LIZARD_TOKEN=lzd_xxx +``` + + + +## Siehe auch + +- [lizard logout](/cli/logout) — abmelden +- [lizard whoami](/cli/whoami) — aktuellen Benutzer, aktiven Workspace und verknüpftes Projekt anzeigen +- [CLI reference](/cli) — globale Flags, Exit-Codes und Überblick über die Authentifizierung diff --git a/_locales/de/cli/logout.mdx b/_locales/de/cli/logout.mdx new file mode 100644 index 0000000..207e1c4 --- /dev/null +++ b/_locales/de/cli/logout.mdx @@ -0,0 +1,22 @@ +--- +description: "lizard logout meldet dich aus der Lizard CLI ab und löscht die auf diesem Rechner gespeicherten Anmeldedaten. Melde dich mit lizard login wieder an." +--- + +# lizard logout + +Abmelden. + + + +## Verwendung + +```bash +lizard logout +``` + + + +## Siehe auch + +- [lizard login](/cli/login) — bei Lizard authentifizieren +- [lizard whoami](/cli/whoami) — den aktuellen Benutzer, den aktiven Workspace und das verknüpfte Projekt anzeigen diff --git a/_locales/de/cli/logs.mdx b/_locales/de/cli/logs.mdx new file mode 100644 index 0000000..8b88099 --- /dev/null +++ b/_locales/de/cli/logs.mdx @@ -0,0 +1,91 @@ +--- +description: "lizard logs streamt die Laufzeit-Logs eines Service oder ruft Build-Logs, Neustart-Logs und gefilterten Verlauf mit --build, --tail und --level ab." +--- + +# lizard logs + +Streamt die Laufzeit-Logs eines Service, die letzten 200 Zeilen gefolgt von einem Live-Tail. + + + +## Verwendung + +```bash +lizard logs [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `--build` | Stattdessen Build-Logs anzeigen | +| `--tail ` | Letzte N Zeilen (max. 1000) | +| `-l, --level ` | Nach Level filtern | +| `--restarts [n]` | Kürzliche Neustarts auflisten | +| `--restart ` | Logs rund um einen bestimmten Neustart (`latest` für den neuesten) | +| `-s, --service ` | Service | + +Mit `--json` ist `lizard logs` kein Stream — es gibt die letzten 200 Zeilen zurück (mit `--tail N` überschreibbar, max. 1000) und beendet sich. Verwende das für Snapshots und Skripting; live streamen nur ohne `--json`. + + + +## Beispiele + + + +### Laufzeit-Logs tailen + +```bash +lizard logs +``` + + + +### Logs für einen bestimmten Service tailen + +```bash +lizard logs --service api +``` + + + +### Mehr Verlauf abrufen + +```bash +lizard logs --tail 1000 +``` + + + +### Nach Log-Level filtern + +```bash +lizard logs --level error +``` + + + +### Den neuesten Build prüfen + +```bash +lizard logs --build +``` + + + +### Einen Absturz oder Neustart untersuchen + +```bash +lizard logs --restarts +lizard logs --restart latest +lizard logs --restart +``` + + + +## Siehe auch + +- [Logs](/observability/logs) — Verhalten von Laufzeit-, Build- und Neustart-Logs sowie Blättern durch den Verlauf mit `lizard service logs` +- [Incomplete Dockerfile](/deploy/troubleshooting/incomplete-dockerfile) — Diagnose eines fehlgeschlagenen Builds aus `lizard logs --build` +- [lizard events](/cli/events) — Bereitstellen-Verlauf und Replikat-Status +- [Von Claude Code bereitstellen](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) — die Schleife aus Logs lesen, beheben und erneut deployen, die ein Agent bei einem fehlgeschlagenen Build ausführt diff --git a/_locales/de/cli/metrics.mdx b/_locales/de/cli/metrics.mdx new file mode 100644 index 0000000..f3bd4ef --- /dev/null +++ b/_locales/de/cli/metrics.mdx @@ -0,0 +1,66 @@ +--- +description: "lizard metrics zeigt CPU, Arbeitsspeicher, Netzwerk und Festplatte für einen Service an, mit einer Live-Ansicht per --watch und optionalen Kostenangaben." +--- + +# lizard metrics + +CPU / Arbeitsspeicher / Netzwerk / Festplatte und Kosten anzeigen. + + + +## Verwendung + +```bash +lizard metrics [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-r, --range ` | Zeitfenster | +| `-w, --watch` | Live-Aktualisierung | +| `--cost` | Kosten einschließen | + + + +## Beispiele + + + +### Metriken für den aktuellen Service anzeigen + +```bash +lizard metrics +``` + + + +### Metriken für einen bestimmten Service anzeigen + +```bash +lizard metrics --service api +``` + + + +### Metriken live beobachten + +```bash +lizard metrics --watch +``` + + + +### Kosten einschließen + +```bash +lizard metrics --cost +``` + + + +## Siehe auch + +- [Metriken & Kosten](/observability/metrics) — Dashboard-Ansichten und auf Nutzung reagieren +- [Skalierung](/deploy/scaling) — Größe anpassen oder Replikate als Reaktion auf Metriken hinzufügen diff --git a/_locales/de/cli/open.mdx b/_locales/de/cli/open.mdx new file mode 100644 index 0000000..f30caa0 --- /dev/null +++ b/_locales/de/cli/open.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard open startet das Dashboard des aktuellen Projekts in deinem Browser, den visuellen Begleiter zur CLI." +--- + +# lizard open + +Projekt im Browser öffnen. + + + +## Verwendung + +```bash +lizard open +``` + + + +## Beispiele + + + +### Dashboard des aktuellen Projekts öffnen + +```bash +lizard open +``` + + + +## Siehe auch + +- [Dashboard](/dashboard) — der visuelle Begleiter zur CLI, den dieser Befehl öffnet +- [Eine Antigravity-App in die Produktion deployen](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command) — dabei zusehen, wie ein agentengesteuertes Deployment ankommt, ohne selbst einen Befehl einzugeben diff --git a/_locales/de/cli/port.mdx b/_locales/de/cli/port.mdx new file mode 100644 index 0000000..8ae0423 --- /dev/null +++ b/_locales/de/cli/port.mdx @@ -0,0 +1,57 @@ +--- +description: "lizard port zeigt den Container-Port eines Service an oder ändert ihn. Wenn du ihn auf 0 setzt, wechselt der Service in den Worker-Modus ohne eingehendes Routing." +--- + +# lizard port + +Zeigt den Container-Port eines Service an oder ändert ihn. Ohne Argument wird der aktuelle Port ausgegeben (`worker mode`, wenn er `0` ist). + + + +## Verwendung + +```bash +lizard port [value] [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-s, --service ` | Ziel-Service | + + + +## Beispiele + + + +### Den aktuellen Port anzeigen + +```bash +lizard port +``` + + + +### Den Port für einen bestimmten Service festlegen + +```bash +lizard port 0 -s worker +``` + + + +### Den Port eines Worker-Service prüfen + +```bash +lizard port --service worker +``` + + + +## Siehe auch + +- [Background workers](/deploy/workers) — setze den Port auf `0`, um einen Service ohne eingehendes Routing auszuführen +- [lizard service](/cli/service) — den Rest der Konfiguration eines Service verwalten +- [Was eine Python-App vom Host braucht](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) — warum ein `gunicorn`- oder `uvicorn`-Prozess `$PORT` an `0.0.0.0` binden muss diff --git a/_locales/de/cli/project.mdx b/_locales/de/cli/project.mdx new file mode 100644 index 0000000..604685c --- /dev/null +++ b/_locales/de/cli/project.mdx @@ -0,0 +1,56 @@ +--- +description: "lizard project listet die Projekte in Ihrem Workspace auf oder erstellt ein neues, mit Beispielen für beide Unterbefehle." +--- + +# lizard project + +Projekte in einem Workspace auflisten oder erstellen. + + + +## Verwendung + +```bash +lizard project list +lizard project create +``` + + + +## Unterbefehle + +### `lizard project list` + +Alle Projekte im Workspace auflisten. + +### `lizard project create` + +Ein neues Projekt erstellen. + + + +## Beispiele + + + +### Projekte im Workspace auflisten + +```bash +lizard project list +``` + + + +### Ein neues Projekt erstellen + +```bash +lizard project create +``` + + + +## Siehe auch + +- [lizard init](/cli/init) — ein Projekt erstellen oder auswählen und mit dem aktuellen Verzeichnis verknüpfen +- [lizard link](/cli/link) — das aktuelle Verzeichnis einem vorhandenen Projekt zuordnen +- [Architecture](/concepts/architecture) — wie Projekte mit Workspaces und Services zusammenhängen diff --git a/_locales/de/cli/ps.mdx b/_locales/de/cli/ps.mdx new file mode 100644 index 0000000..9750432 --- /dev/null +++ b/_locales/de/cli/ps.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard ps listet jeden Service im verknüpften Projekt mit seinem Status und seiner Live-URL auf, eine schnelle Übersicht darüber, was läuft." +--- + +# lizard ps + +Alle Services im Projekt mit Status und URL auflisten. + + + +## Verwendung + +```bash +lizard ps +``` + + + +## Beispiele + + + +### Services im verknüpften Projekt auflisten + +```bash +lizard ps +``` + + + +## Siehe auch + +- [lizard status](/cli/status) — den verknüpften Workspace, das Projekt und den Service für das aktuelle Verzeichnis anzeigen +- [lizard events](/cli/events) — Deployment-Verlauf und Replikatstatus anzeigen diff --git a/_locales/de/cli/redeploy.mdx b/_locales/de/cli/redeploy.mdx new file mode 100644 index 0000000..619b9e8 --- /dev/null +++ b/_locales/de/cli/redeploy.mdx @@ -0,0 +1,67 @@ +--- +description: "lizard redeploy löst einen frischen Build aus dem neuesten Commit oder Upload mit den aktuellen Variablen aus und streamt Logs, außer wenn du --detach übergibst." +--- + +# lizard redeploy + +Löst einen frischen Build aus (neuester Commit / letzter Upload) mit den aktuellen Variablen. + + + +## Verwendung + +```bash +lizard redeploy [nameOrId] [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|--------------| +| `-s, --service ` | Service | +| `--detach` | Gibt zurück, nachdem der Build akzeptiert wurde | +| `--wait` | Wartet auf den Build und die Bereitstellung der Deployment-Readiness; funktioniert mit `--json` | +| `--timeout ` | Zeitbudget für das Warten auf Readiness nach dem Build; Standard `120` | +| `--json` | Gibt JSON für Skripte zurück | + + + +## Beispiele + + + +### Service neu bauen und erneut deployen + +```bash +lizard redeploy --service api +``` + + + +### Erneut deployen, ohne Logs zu streamen + +```bash +lizard redeploy --service api --detach +``` + + + +### In einem Skript warten + +Erfordert CLI 0.3.94 oder neuer. Verwende 0.3.95 oder neuer für Worker ohne HTTP. + +```bash +lizard --json redeploy --service api --wait --timeout 120 +``` + +Ohne `--wait` gibt der JSON-Modus zurück, nachdem die Build-Anfrage akzeptiert wurde. Mit `--wait` verfolgt die CLI diesen Build und wartet dann auf die Deployment-Readiness. Das JSON-Ergebnis enthält `buildId`, `ok` und `status`. Ein fehlgeschlagener Build, eine fehlgeschlagene Readiness-Prüfung oder ein Timeout liefern einen Exit-Code ungleich null zurück. + +Das Timeout gilt für die Readiness, nachdem der Build abgeschlossen ist; es begrenzt nicht die Build-Dauer und bricht das Deployment nicht ab. Worker mit `containerPort=0` verwenden den Readiness-Status aus dem Backend ohne HTTP-Prüfung. Prüfe nach einem erfolgreichen Befehl einen Anwendungsendpunkt oder gespeicherte Daten, wenn dein Workflow das Anwendungsverhalten verifizieren muss. + + + +## Siehe auch + +- [lizard restart](/cli/restart) — Rolling-Restart des aktuellen Builds, kein Neubau +- [lizard up](/cli/up) — lädt das aktuelle Verzeichnis hoch und deployt es +- [Bereitstellungen](/concepts/deployments) — wie Deploys, Neustarts und Rebuilds funktionieren diff --git a/_locales/de/cli/regions.mdx b/_locales/de/cli/regions.mdx new file mode 100644 index 0000000..29e3a1f --- /dev/null +++ b/_locales/de/cli/regions.mdx @@ -0,0 +1,62 @@ +--- +description: "lizard regions listet die für Ihr Konto verfügbaren Regionen auf und zeigt, wie Sie --region beim Erstellen eines Service oder Add-ons übergeben." +--- + +# lizard regions + +Verfügbare Regionen auflisten. + + + +## Verwendung + +```bash +lizard regions [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `--json` | Als JSON ausgeben | + + + +## Beispiele + + + +### Verfügbare Regionen auflisten + +```bash +lizard regions +``` + + + +### Regionen als JSON auflisten + +```bash +lizard regions --json +``` + + + +### Beim Erstellen eines Service oder Add-ons eine Region auswählen + +Übergeben Sie `--region ` an `lizard add` oder `lizard up`: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +Wenn Sie keine Region angeben, verwendet die Plattform den Standard des Projekts. + + + +## Siehe auch + +- [Regionen](/deploy/regions) — Regionsauswahl, Co-Location und generierte Domains +- [`lizard add`](/cli/add) — einen Service, ein Repo oder ein Add-on mit `--region` hinzufügen diff --git a/_locales/de/cli/restart.mdx b/_locales/de/cli/restart.mdx new file mode 100644 index 0000000..44cbf64 --- /dev/null +++ b/_locales/de/cli/restart.mdx @@ -0,0 +1,73 @@ +--- +description: "lizard restart führt einen Rolling-Restart des aktuellen Builds eines Dienstes ohne Rebuild aus und ist nützlich, um sich von einem Absturz zu erholen." +--- + +# lizard restart + +Rolling-Restart des aktuellen Builds — kein Rebuild. + + + +## Verwendung + +```bash +lizard restart [nameOrId] [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|--------------| +| `-s, --service ` | Dienst | +| `--detach` | Nach Annahme des Restarts zurückkehren | +| `--wait` | Warten, bis der neue Restart-Versuch bereit ist; funktioniert mit `--json` | +| `--timeout ` | Wartebudget für Bereitschaft mit `--wait`; Standard `120` | +| `--json` | JSON für Skripte zurückgeben | + + + +## Beispiele + + + +### Einen Dienst neu starten + +```bash +lizard restart --service api +``` + + + +### Neustart ohne Streaming-Logs + +```bash +lizard restart --service api --detach +``` + + + +### Vor der nächsten Prüfung warten + +Erfordert CLI 0.3.94 oder neuer. Verwende 0.3.95 oder neuer für Worker ohne HTTP. + +```bash +lizard --json restart --service api --wait --timeout 120 +``` + +Ohne `--wait` gibt der JSON-Modus nach Annahme des Restarts zurück. Mit `--wait` enthält das Ergebnis `ok`, `status`, `attemptId` und `waitedMs`. Die CLI wartet auf einen neuen Restart-Versuch, daher zählt ein unveränderter Status von vor der Anfrage nicht als Erfolg. Ein fehlgeschlagenes Warten oder ein Timeout liefert einen Exit-Code ungleich null zurück. + +Bei HTTP-Diensten prüft die CLI zusätzlich die Dienst-Domain zweimal. Worker mit `containerPort=0` verwenden den Bereitschaftsstatus aus dem Backend und benötigen keinen HTTP-Listener, selbst wenn sie eine generierte Domain haben. + +```bash +lizard --json restart --service worker --wait --timeout 60 +``` + +Das Timeout gilt für das Warten auf Bereitschaft nach der Restart-Anfrage. Es bricht den Restart nicht ab, und Netzwerkaufrufe können dazu führen, dass der gesamte Befehl länger dauert. Prüfe nach dem Befehl Anwendungsdaten oder einen Health-Endpunkt, wenn dein Workflow mehr als Prozessbereitschaft benötigt. + + + +## Siehe auch + +- [lizard redeploy](/cli/redeploy) — einen frischen Build auslösen, statt den aktuellen wiederzuverwenden +- [lizard logs](/cli/logs) — Logs rund um einen Restart mit `--restart latest` oder `--restart ` prüfen +- [Bereitstellungen](/concepts/deployments) — Restarts vs. Redeploys und Wiederherstellung nach einem Absturz diff --git a/_locales/de/cli/run.mdx b/_locales/de/cli/run.mdx new file mode 100644 index 0000000..a5aeba4 --- /dev/null +++ b/_locales/de/cli/run.mdx @@ -0,0 +1,61 @@ +--- +description: "lizard run führt einen Befehl auf deinem Rechner mit eingefügten Projekt- und Service-Geheimnissen eines Service aus. Enthält auch, wann du stattdessen ssh verwenden solltest." +--- + +# lizard run + +Führe einen Befehl lokal mit eingefügten Projekt- und Service-Geheimnissen aus. + +## run vs. ssh + +Mit zwei Befehlen kannst du Befehle im Kontext eines Service ausführen. Sie laufen an unterschiedlichen Orten — du solltest wissen, welchen du brauchst. + +| Befehl | Wird ausgeführt in | Verwenden für | +|---------|-----------|---------| +| `lizard run` | Lokal, mit eingefügten Projekt- und Service-Geheimnissen des Service | Migrationen, Seed-Skripte, lokale Tools, die eine Produktionskonfiguration brauchen | +| `lizard ssh` | Innerhalb des laufenden Service-Containers | Den Live-Container untersuchen, einmalige Remote-Befehle, Debugging | + +`lizard run` zeigt deine lokal eingefügte Kopie der Umgebung an, die normalerweise mit dem übereinstimmt, was die laufende App sieht — aber `lizard ssh` ist für den Live-Container maßgeblich. Um zu prüfen, was die laufende App tatsächlich sieht, verwende stattdessen `lizard ssh`. + + + +## Verwendung + +```bash +lizard run [flags] -- +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-s, --service ` | Service, dessen env eingefügt werden soll | +| `--no-service` | Service-env nicht einfügen | + + + +## Beispiele + + + +### Eine Migration mit eingefügten Service-Geheimnissen ausführen + +```bash +lizard run --service api -- node scripts/migrate.js +``` + + + +### Eine eingefügte Umgebungsvariable ausgeben + +```bash +lizard run --service api -- printenv DATABASE_URL +``` + + + +## Siehe auch + +- [lizard ssh](/cli/ssh) — einen Befehl innerhalb des laufenden Service-Containers statt lokal ausführen +- [Variablen](/variables) — wie Projekt- und Service-Variablen definiert und referenziert werden +- [Python-App-Hosting](https://lizard.build/blog/python-app-hosting) — `manage.py` und andere Framework-Tools gegen eine bereitgestellte Datenbank ausführen diff --git a/_locales/de/cli/scale.mdx b/_locales/de/cli/scale.mdx new file mode 100644 index 0000000..c113594 --- /dev/null +++ b/_locales/de/cli/scale.mdx @@ -0,0 +1,65 @@ +--- +description: "lizard scale ändert die Replikas, CPU und den Arbeitsspeicher eines Service und vergrößert den Add-on-Speicher. Zulässige Werte und Beispiele für jedes Flag." +--- + +# lizard scale + +Skaliert einen Service (Replikas / CPU / Arbeitsspeicher / Speicher). + + + +## Verwendung + +```bash +lizard scale [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `--replicas ` | Replikas `1`–`10` (Apps) | +| `--cpu ` | `1`, `2`, `3` oder `4` | +| `--memory ` | `128`–`8192` MB | +| `--storage ` | Größe des Add-on-Volumes, nur vergrößerbar | + + + +## Beispiele + + + +### Replikas horizontal skalieren + +```bash +lizard scale --service api --replicas 5 +``` + +Jede Replika ist ein eigener Pod hinter dem Load Balancer. Stelle sicher, dass deine App zustandslos ist, damit Replikas austauschbar sind. + + + +### CPU und Arbeitsspeicher vertikal skalieren + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +### Add-on-Speicher vergrößern + +```bash +lizard scale --service postgres --storage 8192 +``` + +Daten-Volumes von Addons sind nur vergrößerbar — du kannst den Speicher erhöhen, aber nicht verkleinern. + + + +## Siehe auch + +- [Scaling](/deploy/scaling) — horizontale vs. vertikale Skalierung und Vergrößern des Add-on-Speichers +- [lizard metrics](/cli/metrics) — CPU / Arbeitsspeicher / Netzwerk / Festplatte vor und nach der Skalierung prüfen +- [lizard ps](/cli/ps) — Replika-Status nach einer Skalierungsänderung prüfen +- [Observability → Metrics](/observability/metrics) — Ressourcen- und Kostenüberwachung diff --git a/_locales/de/cli/secrets.mdx b/_locales/de/cli/secrets.mdx new file mode 100644 index 0000000..2c9baac --- /dev/null +++ b/_locales/de/cli/secrets.mdx @@ -0,0 +1,100 @@ +--- +description: "lizard secrets setzt, listet, löscht und importiert Umgebungsvariablen auf Service- oder Projektebene, einschließlich dotenv-Import von stdin." +--- + +# lizard secrets + +Verwalte die Secrets (Umgebungsvariablen) eines Projekts oder Services. + + + +## Verwendung + +```bash +lizard secrets [args] [flags] +``` + + + +## Unterbefehle + +### `lizard secrets set ...` + +Setzt ein oder mehrere Secrets (variadisch). Der Standardbereich ist der Service; `--global` zielt auf das Projekt. + +| Flag | Beschreibung | +|------|-------------| +| `--global` | Projektbereich | +| `-s, --service ` | Servicebereich | + +### `lizard secrets list` + +Listet Secrets im Bereich auf. + +| Flag | Beschreibung | +|------|-------------| +| `--show` | Werte anzeigen | +| `--ref` | Referenzen anzeigen | + +### `lizard secrets delete ...` + +Löscht ein oder mehrere Secrets (variadisch). + +### `lizard secrets import` + +Importiert eine dotenv-Datei von stdin. + + + +## Beispiele + + + +### Secrets für den verknüpften Service setzen + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + + + +### Ein projektweites Secret setzen + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +### Secrets auflisten und anzeigen + +```bash +lizard secrets list +lizard secrets list --show +``` + + + +### Secrets löschen + +```bash +lizard secrets delete OLD_KEY ANOTHER_KEY +``` + + + +### Eine dotenv-Datei importieren + +```bash +cat .env | lizard secrets import +``` + + + +## Siehe auch + +- [Variablen & Secrets](/variables) — Bereich, Priorität und Verhalten zur Build-Zeit vs. Laufzeit +- [Service-übergreifende Referenzen](/variables/references) — Werte eines Services aus einem anderen lesen +- [Fehlerbehebung: Ein Secret oder eine Referenz wird nicht angezeigt](/variables/troubleshooting/reference-not-applied) +- [lizard run](/cli/run) — einen Befehl lokal mit eingefügten Projekt- + Service-Secrets ausführen diff --git a/_locales/de/cli/service.mdx b/_locales/de/cli/service.mdx new file mode 100644 index 0000000..d63321e --- /dev/null +++ b/_locales/de/cli/service.mdx @@ -0,0 +1,95 @@ +--- +description: "lizard service liest und bearbeitet die Build-, Start-, Source- und Variablen-Einstellungen eines Service und verwaltet Umbenennen, Löschen, Logs und Verknüpfen." +--- + +# lizard service + +Verwalte die Konfiguration, Source und den Lebenszyklus eines einzelnen Service. + + + +## Verwendung + +```bash +lizard service set [flags] +lizard service show [flags] +lizard service rename +lizard service delete [flags] +lizard service logs +lizard service link +``` + + + +## Unterbefehle + +### `lizard service set` + +Wende Änderungen an Build/Start/Source/Variablen/Umbenennen auf einen Service an. + +| Flag | Beschreibung | +|------|-------------| +| `--set =` | Ein Feld setzen (wiederholbar) | +| `-f, --file ` | JSON-Konfigurationsdatei zum Anwenden | +| `--force` | Auch dann überschreiben, wenn es remote geändert wurde | + +Häufige Felder sind flach und entsprechen 1:1 dem Wire-Schema: `sourceType`, `repoUrl`, `branch`, `rootDirectory`, `dockerfilePath`, `buildCommand`, `startCommand`, `preDeployCommand`, `watchPatterns`, `containerPort`, `name`. + +`service set` verwendet optimistische Nebenläufigkeit über `configRevision`. Bei einem `409` lies die Konfiguration mit `lizard service show` erneut, gleiche sie ab und versuche es noch einmal — oder übergib `--force`. + +### `lizard service show` + +Zeige die aktuelle Service-Konfiguration als JSON an. Verwende `-s`, um sie auf einen Service zu beschränken. + +### `lizard service rename` + +Benenne einen Service oder ein Add-on um. Verweise darauf (`${{name.KEY}}`) bleiben stabil. + +### `lizard service delete` + +Lösche einen Service. `-y, --yes` überspringt die Bestätigung. + +### `lizard service logs` + +Streame die Logs eines Service (siehe auch [lizard logs](/cli/logs)). + +### `lizard service link` + +Verknüpfe einen Service mit dem aktuellen Verzeichnis. + + + +## Beispiele + + + +### Build- und Start-Befehle eines Service aktualisieren + +```bash +lizard service set api --set branch=main --set buildCommand="npm run build" +``` + + + +### Vollständige Konfiguration eines Service prüfen + +```bash +lizard service show -s api +``` + + + +### Einen Service ohne Bestätigungsabfrage löschen + +```bash +lizard service delete -y +``` + + + +## Siehe auch + +- [lizard port](/cli/port) — Container-Port eines Service anzeigen oder ändern +- [lizard scale](/cli/scale) — Replikate, CPU, Arbeitsspeicher oder Storage eines Service skalieren +- [Architecture](/concepts/architecture) — wie Services mit Projekten und Add-ons zusammenhängen +- [Build pipeline](/concepts/build-pipeline) — wie `buildCommand`, `startCommand` und Source-Einstellungen zur Build-Zeit verwendet werden diff --git a/_locales/de/cli/skills.mdx b/_locales/de/cli/skills.mdx new file mode 100644 index 0000000..e9f9147 --- /dev/null +++ b/_locales/de/cli/skills.mdx @@ -0,0 +1,61 @@ +--- +description: "lizard skills liest die mit deiner CLI-Version gebündelten Agentenleitfäden, sodass ein KI-Agent immer Anweisungen erhält, die zur Binärdatei passen." +--- + +# lizard skills + +Lies die eingebetteten Agenten-Skills, die mit dieser CLI-Version ausgeliefert werden. + + + +## Verwendung + +```bash +lizard skills list +lizard skills get core +lizard skills path +``` + + + +## Unterbefehle + +### `lizard skills list` + +Liste die verfügbaren eingebetteten Skills auf. + +### `lizard skills get core` + +Lies den Core-Anleitung — den maßgeblichen Nutzungsleitfaden für die Plattform, versioniert mit der CLI. Er gibt `{ name, frontmatter, content, … }` zurück, wobei `content` der vollständige Leitfaden ist (Build-Pipeline, env-Priorität, Add-ons, Discovery, Exit-Codes). + +### `lizard skills path` + +Zeige an, wo Skills auf dem Datenträger gespeichert sind. + + + +## Beispiele + + + +### Den Core-Anleitung als Agent laden + +```bash +lizard skills get core --json +``` + + + +### Verfügbare eingebettete Skills auflisten + +```bash +lizard skills list +``` + + + +## Siehe auch + +- [AI agents & MCP](/agents) — wie Agenten mit dem eingebetteten Skill und selbstbeschreibenden Befehlen starten +- [JSON & automation](/cli/json) — das Ausgabeformat `--json`, das von `lizard skills get core --json` verwendet wird +- [Von Claude Code bereitstellen](https://lizard.build/blog/deploy-from-claude-code) — den Skill installieren und das Deployment end-to-end an den Agenten übergeben diff --git a/_locales/de/cli/ssh.mdx b/_locales/de/cli/ssh.mdx new file mode 100644 index 0000000..943f862 --- /dev/null +++ b/_locales/de/cli/ssh.mdx @@ -0,0 +1,70 @@ +--- +description: "lizard ssh führt einen Befehl in einem laufenden Service-Container aus und gibt seinen Exit-Code zurück. Die maßgebliche Methode, um zu sehen, was der Container sieht." +--- + +# lizard ssh + +Führe einen Befehl in dem Container eines laufenden Service aus, streame seine Ausgabe und gib den Remote-Exit-Code zurück. + +## run vs. ssh + +`lizard run` und `lizard ssh` führen beide einen Befehl im Kontext eines Service aus, aber sie laufen an unterschiedlichen Orten — du solltest wissen, welchen du brauchst. + +| Befehl | Wird ausgeführt in | Verwenden für | +|---------|-----------|---------| +| `lizard run` | **Lokal**, mit injiziertem Projekt des Service + Service-Secrets | Migrationen, Seed-Skripte, lokale Tools, die Produktionskonfiguration brauchen | +| `lizard ssh` | **Im laufenden Service-Container** | Den Live-Container inspizieren, einmalige Remote-Befehle, Debugging | + +`lizard run` zeigt deine lokal injizierte Kopie der Umgebung, die normalerweise mit der Produktion übereinstimmt — aber `lizard ssh` ist maßgeblich dafür, was der Live-Container tatsächlich sieht. + + + +## Verwendung + +```bash +lizard ssh --service -- +``` + + + +## Beispiele + + + +### Die Umgebung inspizieren, die die laufende App sieht + +```bash +lizard ssh --service api -- env +``` + + + +### Dateien im bereitgestellten Image auflisten + +```bash +lizard ssh --service api -- ls -la /app +``` + + + +### Das Betriebssystem im Container prüfen + +```bash +lizard ssh --service api -- cat /etc/os-release +``` + + + +### Bestätigen, dass ein Secret im Live-Container angekommen ist + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## Siehe auch + +- [lizard run](/cli/run) — stattdessen einen Befehl lokal mit injizierter Service-Umgebung ausführen +- [Variablen](/variables) — wie Secrets und Referenzen einen Service erreichen +- [Von Claude Code bereitstellen](https://lizard.build/blog/deploy-from-claude-code#claude-code-deployment-compared-with-the-alternatives) — warum ein Agent eine Shell in den laufenden Container braucht und welche Plattformen keine bereitstellen diff --git a/_locales/de/cli/status.mdx b/_locales/de/cli/status.mdx new file mode 100644 index 0000000..93e7d27 --- /dev/null +++ b/_locales/de/cli/status.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard status zeigt, mit welchem Workspace, Projekt und Service das aktuelle Verzeichnis verknüpft ist, damit du nicht versehentlich zum falschen Ziel deployst." +--- + +# lizard status + +Zeigt den verknüpften Workspace, das Projekt und den Service für das aktuelle Verzeichnis an. + + + +## Verwendung + +```bash +lizard status +``` + + + +## Beispiele + + + +### Verknüpfung des aktuellen Verzeichnisses prüfen + +```bash +lizard status +``` + + + +## Siehe auch + +- [lizard init](/cli/init) — ein Projekt erstellen oder auswählen und mit dem aktuellen Verzeichnis verknüpfen +- [lizard link](/cli/link) — das aktuelle Verzeichnis mit einem bestehenden Projekt verknüpfen +- [lizard whoami](/cli/whoami) — den aktuellen Benutzer, den aktiven Workspace und das verknüpfte Projekt anzeigen diff --git a/_locales/de/cli/unlink.mdx b/_locales/de/cli/unlink.mdx new file mode 100644 index 0000000..04890f6 --- /dev/null +++ b/_locales/de/cli/unlink.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard unlink entfernt die Verknüpfung zwischen dem aktuellen Verzeichnis und jedem Projekt, ohne das Projekt selbst zu verändern." +--- + +# lizard unlink + +Löst die Zuordnung des aktuellen Verzeichnisses zu jedem Projekt. + + + +## Verwendung + +```bash +lizard unlink +``` + + + +## Beispiele + + + +### Verknüpfung des aktuellen Verzeichnisses aufheben + +```bash +lizard unlink +``` + + + +## Siehe auch + +- [lizard link](/cli/link) — das aktuelle Verzeichnis einem Projekt zuordnen +- [lizard status](/cli/status) — den verknüpften Workspace, das Projekt und den Service prüfen diff --git a/_locales/de/cli/up.mdx b/_locales/de/cli/up.mdx new file mode 100644 index 0000000..39fa6e6 --- /dev/null +++ b/_locales/de/cli/up.mdx @@ -0,0 +1,86 @@ +--- +description: "lizard up paketiert das aktuelle Verzeichnis, baut es auf den Build-Knoten von Lizard und gibt eine Live-URL zurück. Flags, CI-Verhalten und Beispiele." +--- + +# lizard up + +Das aktuelle Verzeichnis hochladen und bereitstellen. + + + +## Verwendung + +```bash +lizard up [flags] +``` + +`up` paketiert Ihren Arbeitsbaum als Tarball, sendet ihn an die Build-Knoten und stellt ihn bereit. Es erzwingt `sourceType=upload` auf dem Zieldienst, streamt Build-Logs über SSE und gibt nach Abschluss die Live-URL aus. + +Wenn das aktuelle Verzeichnis noch nicht mit einem Projekt verknüpft ist, führt `up` zuerst `init` aus. In einem TTY ist das interaktiv; in einer Nicht-TTY-Umgebung (CI) wird **nicht** stillschweigend ein Projekt erstellt — stattdessen wird ein Fehler ausgegeben und Sie werden aufgefordert, `lizard init --name ` auszuführen (oder `--name` zu übergeben), damit nicht durch einen Tippfehler ein leeres Projekt erzeugt wird. + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `-s, --service ` | Einen vorhandenen Dienst als Ziel verwenden | +| `--build-command ` | Den Build-Befehl überschreiben | +| `--start-command ` | Den Startbefehl überschreiben | +| `--pre-deploy-command ` | Vor jedem Bereitstellen einmal ausführen | +| `--port ` | Container-Port (`0` = Worker-Modus) | +| `--region ` | Region für das Bereitstellen | +| `-d, --detach` | Das Bereitstellen starten und beenden, ohne Logs zu streamen | +| `-c, --ci` | CI-freundliche Ausgabe | +| `--no-gitignore` | Alles hochladen und `.gitignore` ignorieren | + + + +## Unterbefehle + +### `lizard up status` + +Den Status eines laufenden Upload-Deploys melden. + + + +## Beispiele + + + +### Das aktuelle Verzeichnis bereitstellen + +```bash +lizard up +``` + + + +### Auf einem bestimmten Dienst mit benutzerdefiniertem Startbefehl und Port bereitstellen + +Erstellen Sie den benannten Dienst zuerst mit `lizard add --service api`, falls er nicht existiert. + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +### Headless in CI bereitstellen + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard add --service api +lizard up --ci --service api +``` + +Überspringen Sie `lizard add`, wenn der Dienst bereits existiert. Mit Lizard CLI 0.3.92 kann ein fehlgeschlagener Build trotzdem mit Exit-Code `0` enden; prüfen Sie den Build-Status und die bereitgestellte URL, bevor Sie ein CI-Release als erfolgreich markieren. Eine Korrektur steht zur Veröffentlichung aus. Setzen Sie auf macOS außerdem vor einem Upload `COPYFILE_DISABLE=1`, um zusätzliche `._*`-Metadatendateien im Archiv zu vermeiden. Siehe [Framework-Setup](/framework-guides#prepare-the-project). + + + +## Siehe auch + +- [Aus lokalem Code bereitstellen](/deploy/upload) — vollständige Anleitung für Upload-basierte Deploys +- [lizard redeploy](/cli/redeploy) — den letzten Upload neu bauen, ohne erneut hochzuladen +- [lizard init](/cli/init) — ein Projekt vor dem Bereitstellen explizit erstellen oder verknüpfen +- [Worker-Dienste](/deploy/workers) — was `--port 0` bedeutet +- [Einen Container bereitstellen, ohne einen zu konfigurieren](https://lizard.build/blog/container-as-a-service#deploy-a-container-without-configuring-one) — wie sich dieser Befehl unter Container-as-a-Service-Plattformen einordnet diff --git a/_locales/de/cli/upgrade.mdx b/_locales/de/cli/upgrade.mdx new file mode 100644 index 0000000..2e72f2a --- /dev/null +++ b/_locales/de/cli/upgrade.mdx @@ -0,0 +1,48 @@ +--- +description: "lizard upgrade aktualisiert die CLI direkt, oder prüft mit --check, ob eine neuere Version verfügbar ist, ohne sie zu installieren." +--- + +# lizard upgrade + +Aktualisiere die CLI auf die neueste Version. + + + +## Verwendung + +```bash +lizard upgrade [flags] +``` + +## Flags + +| Flag | Beschreibung | +|------|-------------| +| `--check` | Auf eine neuere Version prüfen, ohne sie zu installieren | + + + +## Beispiele + + + +### Auf die neueste Version aktualisieren + +```bash +lizard upgrade +``` + + + +### Ohne Installation auf Updates prüfen + +```bash +lizard upgrade --check +``` + + + +## Siehe auch + +- [CLI-Referenz](/cli) — Installation, globale Flags, Exit-Codes +- [Erste Schritte](/getting-started) — die CLI zum ersten Mal installieren diff --git a/_locales/de/cli/whoami.mdx b/_locales/de/cli/whoami.mdx new file mode 100644 index 0000000..ade6d2d --- /dev/null +++ b/_locales/de/cli/whoami.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard whoami gibt das Konto aus, mit dem Sie angemeldet sind, Ihren aktiven Workspace und das mit diesem Verzeichnis verknüpfte Projekt." +--- + +# lizard whoami + +Zeigt den aktuellen Benutzer, den aktiven Workspace und das verknüpfte Projekt an. + + + +## Verwendung + +```bash +lizard whoami +``` + + + +## Beispiele + + + +### Prüfen, als wer Sie angemeldet sind + +```bash +lizard whoami +``` + + + +## Siehe auch + +- [lizard login](/cli/login) — vor dem Prüfen Ihrer Identität authentifizieren +- [lizard status](/cli/status) — den verknüpften Workspace, das Projekt und den Service für das aktuelle Verzeichnis anzeigen +- [lizard workspace](/cli/workspace) — die Workspaces auflisten, auf die Sie Zugriff haben diff --git a/_locales/de/cli/workspace.mdx b/_locales/de/cli/workspace.mdx new file mode 100644 index 0000000..97be1df --- /dev/null +++ b/_locales/de/cli/workspace.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard workspace list zeigt alle Workspaces, auf die dein Konto zugreifen kann, und wie Workspaces mit Projekten und Services zusammenhängen." +--- + +# lizard workspace + +Liste die Workspaces auf, auf die du zugreifen kannst. + + + +## Verwendung + +```bash +lizard workspace list +``` + + + +## Beispiele + + + +### Deine Workspaces auflisten + +```bash +lizard workspace list +``` + + + +## Siehe auch + +- [lizard whoami](/cli/whoami) — zeigt deinen aktiven Workspace an +- [Architecture: Workspace](/concepts/architecture) — wie Workspaces mit Projekten und Services zusammenhängen diff --git a/_locales/de/concepts/_meta.ts b/_locales/de/concepts/_meta.ts new file mode 100644 index 0000000..04cbe61 --- /dev/null +++ b/_locales/de/concepts/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Überblick", + architecture: "Architektur", + 'build-pipeline': "Build-Pipeline", + deployments: "Bereitstellungen", +}; diff --git a/_locales/de/concepts/architecture.mdx b/_locales/de/concepts/architecture.mdx new file mode 100644 index 0000000..6ab0b76 --- /dev/null +++ b/_locales/de/concepts/architecture.mdx @@ -0,0 +1,122 @@ +--- +description: "Wie Lizard Arbeit in Workspaces, Projekte und Services organisiert, plus verwaltete Addons, ressourcenübergreifende Referenzen und injizierte Variablen." +--- + + + +# Architektur + +Lizard organisiert alles, was Sie deployen, in einer Hierarchie mit drei Ebenen sowie verwalteten Addons, die an ein Projekt angehängt werden. + +``` +workspace +└── project + ├── service (app) ← built from GitHub or an upload + ├── service (worker) ← background job, no HTTP port + └── addons + ├── postgres + ├── redis + └── s3 +``` + +## Workspace + +Ein **Workspace** ist die Konto- oder Organisationsebene. Sie gehören mindestens zu einem Workspace, und Abrechnung, Mitglieder und Projekte sind ihm untergeordnet. Listen Sie die Workspaces auf, auf die Sie zugreifen können: + +```bash +lizard workspace list +lizard whoami # shows your active workspace +``` + +Viele Befehle akzeptieren `-w, --workspace `, um Mehrdeutigkeiten aufzulösen, wenn derselbe Projektname in mehr als einem Workspace existiert. + + + +## Projekt + +Ein **Projekt** gruppiert zusammengehörige Services und Addons innerhalb eines Workspace. Ihr Arbeitsverzeichnis wird mit einem Projekt *verknüpft*, und diese Verknüpfung (gespeichert in `~/.lizard/config.json`) teilt der CLI mit, worauf Sie zielen. + +```bash +lizard init --name my-project # create or select a project, link the cwd +lizard link --project my-project # link to an existing project +lizard status # show the current directory's link +lizard unlink # remove the link +lizard project list # all projects in the workspace +``` + +> **Tipp:** Verwenden Sie für das Projekt den Repo- oder Verzeichnisnamen und für Services app-artige Namen (`api`, `worker`, `web`). + +## Service + +Ein **Service** ist eine einzelne deploybare Einheit. Seine Quelle ist eine der folgenden: + +- **`github`** — ein verbundenes GitHub-Repo. Pushes auf den verfolgten Branch lösen automatisch ein Redeploy aus. +- **`upload`** — ein mit `lizard up` hochgeladenes Tarball. + +Jeder laufende Service läuft in seinem eigenen **isolierten Pod** mit einer Network Policy nach dem Prinzip Standard Deny, einer generierten `..onlizard.com`-Domain und automatischem TLS. Diese Aufteilung — Sie liefern den Container, die Plattform führt ihn aus — ist [container as a service](https://lizard.build/blog/container-as-a-service), und der Blog behandelt, was dabei trotzdem noch bei Ihnen verbleibt. Prüfen und verwalten Sie Services mit: + +```bash +lizard ps # list services with status + URL +lizard service show # full config as JSON +lizard service set --set = +lizard service rename --service +lizard service delete --service +``` + +Felder der Service-Konfiguration sind **flach** und entsprechen 1:1 dem Wire-Schema (z. B. `repoUrl`, `branch`, `buildCommand`, `startCommand`, `containerPort`, `rootDirectory`). Es gibt keine Verschachtelung mit `build.*` / `deploy.*`. Die vollständige Liste finden Sie unter [`lizard service`](/cli/service). + + + +### App- vs. Worker-Services + +Standardmäßig ist ein Service eine **HTTP-App**, die auf einem Port lauscht (Standard: `3000`) und unter ihrer Domain ausgeliefert wird. Ein Service, der nicht auf einem Port lauscht — etwa ein Queue-Consumer, Reconciler oder Polling-Loop — sollte im [**Worker-Modus**](/deploy/workers) laufen, indem `containerPort=0` gesetzt wird. Worker überspringen die Port-Injektion, den Erreichbarkeits-Health-Check und die Registrierung beim Load Balancer. + + + +## Verwaltete Addons + +**Addons** sind verwaltetes Postgres, Redis und S3-kompatibler Storage, die Sie pro Projekt bereitstellen: + +```bash +lizard add postgres redis s3 +``` + +Jedes Add-on stellt einen festen Satz an Umgebungsvariablen bereit, den Ihre Services per **Referenz** verwenden (`${{.KEY}}`). Siehe [Managed Addons](/addons). + + + +## Ressourcenübergreifende Referenzen + +Jeder Wert eines Service oder Addons kann aus der Umgebung einer anderen Ressource referenziert werden mit: + +``` +${{.}} +``` + +Referenzen werden zur **Bereitstellen-Zeit** gegen die zusammengeführte Umgebung des Ziels aufgelöst. Sie werden per ID gespeichert, daher bricht ein späteres Umbenennen des Ziels die Referenz nicht. Eine Referenz auf ein fehlendes Ziel oder einen fehlenden Schlüssel wird zu einer leeren Zeichenfolge aufgelöst (das Bereitstellen schlägt **nicht** fehl); nur zirkuläre Referenzen führen zu einem Fehler. + +```bash +# Wire a service to the project's Postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + +Prüfen Sie, ob der Consumer den Wert tatsächlich erhalten hat: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## Von der Plattform injizierte Variablen + +Jeder Service erhält automatisch diese Variablen (sie können nicht überschrieben werden): + +| Variable | Beschreibung | +|----------|-------------| +| `PORT` | Port, auf dem Ihre App lauschen soll (im Worker-Modus weggelassen) | +| `LIZARD_SERVICE_NAME` | Der Name des Service | +| `LIZARD_PROJECT_ID` | Die Projekt-ID | +| `LIZARD_PUBLIC_DOMAIN` | Die öffentliche Domain des Service | + +Unter [Variablen & Secrets](/variables) erfahren Sie, wie diese mit Ihren eigenen Variablen interagieren und wie die vollständige Prioritätsreihenfolge aussieht. diff --git a/_locales/de/concepts/build-pipeline.mdx b/_locales/de/concepts/build-pipeline.mdx new file mode 100644 index 0000000..3f8a00d --- /dev/null +++ b/_locales/de/concepts/build-pipeline.mdx @@ -0,0 +1,87 @@ +--- +description: "Wie Lizard Quellcode in ein Container-Image verwandelt: synthetisierte Dockerfile, Dockerfile aus dem Repo oder automatische Erkennung durch lizardpack – und was einen Neuaufbau auslöst." +--- + +# Build-Pipeline + +Builds laufen auf den Build-Nodes von Lizard — **du brauchst Docker lokal nicht**. Beim Bereitstellen entscheidet die Plattform anhand einer festen Reihenfolge, wie dein Quellcode in ein Container-Image umgewandelt wird, und führt dieses Image dann in einem isolierten Pod aus. Nicht jeder [container as a service](https://lizard.build/blog/container-as-a-service) baut das Image für dich; der Blog vergleicht die drei Varianten, in denen diese Kategorie vorkommt. + + + +## Reihenfolge der Build-Entscheidung + +Die Plattform wählt genau eine Build-Strategie, in dieser Reihenfolge: + +1. **Synthetisierte Dockerfile** — wenn `buildCommand` und/oder `startCommand` im Service gesetzt sind (oder per `lizard up --build-command` / `--start-command` übergeben werden), erzeugt Lizard daraus eine Dockerfile. lizardpack wird nicht aufgerufen. +2. **Dockerfile aus dem Repo (unverändert)** — wenn `dockerfilePath` im Service gesetzt ist, wird diese Dockerfile aus deinem Repo unverändert verwendet. +3. **Automatische Erkennung durch lizardpack** — andernfalls klont die Plattform deinen Quellcode und führt **lizardpack** aus, den eigenen Buildpack-/Dockerfile-Generator. + + + +### Automatische Erkennung durch lizardpack + +lizardpack prüft dein Repo und baut ein optimiertes Multi-Stage-Image. Unterstützte Stacks, in dieser Reihenfolge abgeglichen: + +**Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static** + +Siehe [Framework guides](/framework-guides) für Produktionsskripte, Adapter, Ausgabepfade und Ports. Die Erkennung nutzt Projektdateien und Abhängigkeiten; ein Repository, das zu mehreren Providern passt, folgt dieser Reihenfolge. + +Auf diesem Pfad gilt: + +- Wenn eine `Dockerfile` im Repo existiert **und** einen echten Build-Schritt hat (eine `RUN `-Zeile, nicht nur `COPY dist/`), wird sie unverändert verwendet. +- Andernfalls erzeugt lizardpack die Dockerfile für dich. +- Der **Startbefehl** wird automatisch erkannt: eine `Procfile`-`web:`-Zeile (Python/Ruby) oder `package.json` `scripts.start` (Node) wird automatisch übernommen. Welche genaue Zeile Django, Flask und FastAPI jeweils brauchen, steht unter [Python-App-Hosting](https://lizard.build/blog/python-app-hosting). +- Der **Port** wird aus `EXPOSE`, Framework-Standards oder einer expliziten `PORT`-Umgebungsvariable abgeleitet. + +> **Wichtig:** Eine Dockerfile, die nur vorgebaute Artefakte kopiert (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) **ohne** einen `RUN`-Build-Schritt, gilt als unvollständig und wird von lizardpack neu erzeugt. Füge einen echten Build-Schritt hinzu oder setze `dockerfilePath`, um die unveränderte Verwendung zu erzwingen. + + + +## Was einen Neuaufbau auslöst + +| Aktion | Neuaufbau? | +|--------|-----------| +| `git push` in den verfolgten Branch | ✅ per GitHub-Webhook | +| `lizard redeploy` / `lizard up` | ✅ explizit | +| Ändern von Variablen für `VITE_*` oder `NEXT_PUBLIC_*` | ✅ Build-Zeit-Werte werden fest ins Image übernommen | +| `service set` von Build-Feldern (`repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath`, `rootDirectory`) | ✅ löst automatisch einen Neuaufbau aus | +| `service set` von reinen Laufzeitfeldern (`startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns`) | ❌ führe `lizard redeploy` aus, damit es angewendet wird | +| Jede andere Änderung an Umgebungsvariablen / Secrets | ❌ wird bei einem schnellen Neustart angewendet (kein Neuaufbau) | + +> **Nicht doppelt bauen.** Nach einem `service set`, das ein Build-Feld ändert, startet der Neuaufbau automatisch — hänge nicht noch ein `lizard redeploy` direkt danach an, sonst stellst du einen zweiten, überflüssigen Build in die Warteschlange. + + + +## Einen Build beobachten + +Build-Logs werden während `lizard up` gestreamt. Für jeden Service: + +```bash +lizard logs --build # the most recent build's logs +lizard events # deploy history + replica status +``` + +Wenn ein Build fehlschlägt, lies `lizard logs --build`, behebe die Ursache (in deinem Repo oder durch Anpassen von `buildCommand` / `startCommand` per `lizard service set`) und führe dann `lizard redeploy` aus. + + + +## Hinweise zur Laufzeit + +- **Keine Docker-`HEALTHCHECK`.** Die Laufzeit führt keine Docker-Healthcheck-Schleife aus, daher werden `HEALTHCHECK`-Direktiven ignoriert. Lizard führt stattdessen einen TCP-Probe gegen deinen Port aus (im [worker mode](/deploy/workers) übersprungen). +- **Schreibe nicht ungefragt eine Dockerfile.** lizardpack erkennt die meisten Stacks automatisch — versuche zuerst ein Bereitstellen und füge nur dann eine Dockerfile hinzu (oder setze `dockerfilePath`), wenn der Auto-Build nicht passt. + + + +## Referenz der Build-Konfiguration + +| Feld | Beschreibung | +|-------|-------------| +| `buildCommand` | Befehl zum Bauen deiner App → erzwingt den Pfad **synthetisierte Dockerfile** | +| `startCommand` | Befehl zum Starten deiner App zur Laufzeit | +| `preDeployCommand` | Wird vor jedem Bereitstellen einmal ausgeführt (z. B. DB-Migrationen) | +| `dockerfilePath` | Pfad zu einer Dockerfile im Repo, die **unverändert** verwendet wird | +| `rootDirectory` | Unterverzeichnis, aus dem gebaut wird (Monorepos) | +| `watchPatterns` | Nur neu deployen, wenn sich passende Pfade ändern | +| `containerPort` | TCP-Port, auf dem deine App lauscht (Standard `3000`; `0` = [worker](/deploy/workers)) | + +Setze beliebige davon mit `lizard service set --set =`. Siehe [`lizard service`](/cli/service). diff --git a/_locales/de/concepts/deployments.mdx b/_locales/de/concepts/deployments.mdx new file mode 100644 index 0000000..8575fdb --- /dev/null +++ b/_locales/de/concepts/deployments.mdx @@ -0,0 +1,95 @@ +--- +description: "Der Bereitstellen-Lebenszyklus auf Lizard: was einen Build auslöst, wie der Traffic auf fehlerfreie Replikate umgeschaltet wird und wie sich Neustarts von Redeploys unterscheiden." +--- + + + +# Bereitstellungen + +Ein **Deployment** ist ein Build-und-Release eines Service. Der Release-Ablauf hängt von der Laufzeitumgebung des Service ab. Ein erfolgreicher Build belegt für sich allein nicht, dass die Anwendung gestartet ist oder Anfragen verarbeiten kann. + + + +## Wie ein Bereitstellen erfolgt + +Ein Deployment wird ausgelöst durch: + +- Ein **`git push`** auf den verfolgten Branch (bei Services mit **`github`**-Quelle). +- **`lizard redeploy`** — Neuaufbau vom neuesten Commit (git) oder letzten Upload mit den aktuellen Variablen. +- **`lizard up`** — lädt das aktuelle Verzeichnis hoch und deployt es. +- Ein **`service set`**, das ein buildrelevantes Feld ändert. + +```bash +lizard redeploy --service api # rebuild + redeploy from current source +lizard up # upload cwd and deploy +``` + + + +## Ablauf + +1. **Build** — die Plattform führt Ihren Build aus (siehe [Build-Pipeline](/concepts/build-pipeline)). +2. **Vor dem Bereitstellen** — wenn `preDeployCommand` gesetzt ist, wird es einmal ausgeführt (z. B. Migrationen). +3. **Start** — Lizard startet die Anwendung für ihre konfigurierte Laufzeitumgebung. +4. **Health-Checks** — die Plattform prüft, ob der Port der App erreichbar ist (entfällt bei [Workers](/deploy/workers)). +5. **Prüfen** — prüfen Sie den Release-Status und rufen Sie die Anwendungs-URL auf. Die Erreichbarkeit des Ports ist kein vollständiger Health-Checks der Anwendung. + + + +## Streaming-Ausgabe + +Wenn Sie ein nicht-detachtes `lizard up` (oder `redeploy`) ausführen, werden Build-Logs live gestreamt. Mit `--json` erhalten Sie ein JSON-Ereignis pro Zeile: + +```json +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "...", "url": "https://..." } +``` + +endet mit `deployed`, `failed` oder `deploying`. Verwenden Sie `--detach`, um das Bereitstellen zu starten und sofort zurückzukehren, ohne Streaming. + + + +## Verlauf prüfen + +```bash +lizard events # deploy history + per-replica status +lizard events --limit 25 # show more +lizard ps # current services, status, and URLs +``` + +Im [Dashboard](/dashboard) zeigt die Ansicht **Bereitstellungen** die vollständige Zeitleiste, Build-Logs pro Deployment und einen Detailbereich für jedes Release. + + + +## Neustarts vs. Redeploys + +| Befehl | Was es tut | +|---------|--------------| +| `lizard restart --service ` | Neustart des **aktuellen** Builds — kein Neuaufbau | +| `lizard redeploy --service ` | Neuer **Build** vom neuesten Commit/Upload, dann Release | + +Verwenden Sie `restart`, um Replikate neu zu starten (z. B. um ein Runtime-Secret zu übernehmen, das nicht per Hot-Reload geladen wurde); verwenden Sie `redeploy`, wenn Sie einen neuen Build benötigen. + + + +## Wiederherstellung nach einem Absturz + +Prüfen Sie die Logs des letzten Absturzes oder Neustarts: + +```bash +lizard logs --restart latest # log tail around the latest restart +lizard logs --restart # a specific restart +lizard events # see replica status +``` + + + +## Konfigurationsänderungen (kein Neuaufbau) + +Die meisten Änderungen an Umgebungsvariablen und Secrets werden ohne Neuaufbau übernommen: Lizard aktualisiert die Konfiguration des Service und startet ihn neu, was einige Sekunden dauert. Build-Zeit-Werte (`VITE_*`, `NEXT_PUBLIC_*`) und Änderungen an Build-Feldern erzwingen jedoch einen Neuaufbau — siehe die [Tabelle der Rebuild-Auslöser](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Fehlgeschlagene Releases und Wiederherstellung + +Ein fehlgeschlagener Build und ein fehlgeschlagener Start der Anwendung sind unterschiedliche Fälle. Gehen Sie nicht davon aus, dass ein altes Release in jeder Laufzeitumgebung weiter Anfragen verarbeitet. Prüfen Sie den aktiven Service, die Build-Logs und die Runtime-Logs. `lizard redeploy` baut die ausgewählte Quelle erneut; es ist kein Befehl zum Wiederherstellen eines vorherigen Builds. Setzen Sie bei Bedarf den Quell-Commit zurück, deployen Sie ihn und prüfen Sie das Ergebnis. Siehe [bekannte Probleme](/platform/known-issues). diff --git a/_locales/de/concepts/index.mdx b/_locales/de/concepts/index.mdx new file mode 100644 index 0000000..45926ff --- /dev/null +++ b/_locales/de/concepts/index.mdx @@ -0,0 +1,19 @@ +--- +description: "Das Kernmodell hinter Lizard: wie Ihr Code organisiert ist, wie er gebaut wird und wie ein Release in die Produktion gelangt." +--- + + + +# Konzepte + +Das Kernmodell hinter Lizard: wie Ihr Code organisiert ist, wie er gebaut wird und wie ein Release in die Produktion gelangt. Wenn Sie das einmal gelesen haben, ergibt auch der Rest der Dokumentation Sinn. + +Für das Modell eine Ebene höher — wie eine Plattform heißt, die Ihren Container für Sie ausführt, und worin sie sich von PaaS, FaaS und IaaS unterscheidet — lesen Sie [container as a service](https://lizard.build/blog/container-as-a-service) im Blog. + + + +## In diesem Abschnitt + +- [Architektur](/concepts/architecture) — die Hierarchie workspace → project → service, verwaltete Add-ons und ressourcenübergreifende Referenzen. +- [Build-Pipeline](/concepts/build-pipeline) — wie aus Quellcode ein Container-Image wird (synthetisierte Dockerfile, Dockerfile aus dem Repo oder automatische Erkennung durch lizardpack) und was einen Neubau auslöst. +- [Bereitstellungen](/concepts/deployments) — der Build-und-Release-Lebenszyklus, Neustarts vs. Redeployments und Live-Konfigurationsänderungen. diff --git a/_locales/de/dashboard.mdx b/_locales/de/dashboard.mdx new file mode 100644 index 0000000..9ade32b --- /dev/null +++ b/_locales/de/dashboard.mdx @@ -0,0 +1,84 @@ +--- +description: "Was das Lizard-Dashboard zusätzlich zur CLI bietet: Service-Status, Bereitstellen-Zeitleiste, Live-Logs, Metriken, Datenbrowser, Team und Abrechnung." +--- + +# App-Dashboard + +Das Lizard-Dashboard ist die visuelle Ergänzung zur CLI. Alles, was Sie mit `lizard …` tun, wird hier angezeigt, plus Dinge, die sich mit einer UI einfacher erledigen lassen — Live-Logs, Diagramme, die Datenbrowser und die Team-/Abrechnungsverwaltung. + +Wenn Sie lieber gar kein Terminal öffnen möchten, lassen Sie den Agenten die Befehle ausführen und verfolgen Sie das Ergebnis hier — die Anleitung unter [Bereitstellen einer Antigravity-App in der Produktion](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command), die nur zwei Prompts erfordert und keinerlei Eingaben im Terminal. + +Öffnen Sie es aus der CLI: + +```bash +lizard open # open the current project +lizard docs # open this documentation +``` + + + +## Was im Dashboard enthalten ist + +### Services + +Die Startansicht des Projekts listet jeden Service mit seinem Status-Badge, der generierten Domain und einem schnellen Zugriff auf Logs, Metriken, Secrets und Einstellungen auf. Erstellen Sie neue Services (aus einem GitHub-Repository oder leer) direkt von hier aus. + + + +### Bereitstellungen + +Eine Zeitleiste aller Deploys mit Build-Logs pro Bereitstellen und einer Detailansicht (Commit, Status, Replikate). Das ist das visuelle Gegenstück zu `lizard events` + `lizard logs --build`. + +### Logs + +Live-Streaming von Laufzeit- und Build-Logs mit Such- und Level-Filtern — das UI-Gegenstück zu [`lizard logs`](/observability/logs). + + + +### Metriken & Nutzung + +CPU-, Speicher-, Netzwerk- und Datenträgerdiagramme pro Service sowie eine **Nutzungs**-Ansicht, die Verbrauch und Kosten im gesamten Projekt aufschlüsselt. Entspricht [`lizard metrics --cost`](/observability/metrics). + + + +### Variablen & Secrets + +Verwalten Sie Secrets auf Service- und Projektebene mit maskierten Werten und Unterstützung für Referenzen (`${{…}}`). Siehe [Variablen & Secrets](/variables). + +### Domains + +Fügen Sie benutzerdefinierte Domains hinzu, sehen Sie DNS-Einträge ein und verfolgen Sie den Verifizierungs- und TLS-Status. Siehe [Networking](/networking). + + + +### Browser für Managed Addons + +Jedes Add-on enthält einen Datenbrowser: + +- **Postgres** — ein SQL-/Tabelleneditor zum Abfragen und Bearbeiten von Daten. +- **Redis** — ein Key/Wert-Browser. +- **S3** — ein Bucket- und Objektbrowser mit Upload/Download. + +### GitHub-Integration + +Verbinden Sie die GitHub-App, wählen Sie Repositories aus und verwalten Sie, welche Repos Lizard bauen darf. Siehe [Von GitHub bereitstellen](/deploy/github). + + + +### Einstellungen, Team & Abrechnung + +Projekt- und Workspace-Einstellungen, Einladungen und Rollen für Mitglieder, Ressourcennutzung, Kontoguthaben und optionales automatisches Aufladen. Standardkonten verwenden [pay as you go](/platform/billing) ohne monatliches Abonnement. + +## CLI ↔ Dashboard + +| Aufgabe | CLI | Dashboard-Ansicht | +|------|-----|----------------| +| Bereitstellen-Verlauf | `lizard events` | Bereitstellungen | +| Logs streamen | `lizard logs` | Logs | +| Ressourcendiagramme | `lizard metrics` | Metriken / Nutzung | +| Secrets verwalten | `lizard secrets` | Variablen | +| Benutzerdefinierte Domains | `lizard domain` | Domains | +| Postgres/Redis/S3 durchsuchen | `lizard run` / `lizard ssh` | Add-on-Browser | +| Teammitglieder einladen | — | Team / Einstellungen | + +Verwenden Sie einfach das, was gerade am besten passt — beide arbeiten mit denselben Projekten und Services. diff --git a/_locales/de/deploy/_meta.ts b/_locales/de/deploy/_meta.ts new file mode 100644 index 0000000..255b786 --- /dev/null +++ b/_locales/de/deploy/_meta.ts @@ -0,0 +1,9 @@ +export default { + index: "Übersicht", + github: "Von GitHub deployen", + upload: "Aus lokalem Code deployen", + workers: "Hintergrund-Worker", + scaling: "Skalierung", + regions: "Regionen", + troubleshooting: "Fehlerbehebung", +}; diff --git a/_locales/de/deploy/github.mdx b/_locales/de/deploy/github.mdx new file mode 100644 index 0000000..b8b70ee --- /dev/null +++ b/_locales/de/deploy/github.mdx @@ -0,0 +1,96 @@ +--- +description: "Verbinde ein GitHub-Repo, damit jeder Push in den verfolgten Branch einen Build auslöst und neu bereitstellt – einschließlich privater Repos, Branch-Wechseln und Monorepos." +--- + + + +# Von GitHub deployen + +Ein GitHub-Repo zu verbinden ist der empfohlene Weg, eine App auf Lizard auszuführen: Jeder Push in den verfolgten Branch baut automatisch neu und stellt erneut bereit. + + + +## Einen Service aus einem Repo erstellen + +```bash +lizard add -r your-org/your-app +``` + +Dadurch wird ein `github`-source-Service erstellt, das Repo geklont, der Stack automatisch erkannt ([lizardpack](/concepts/build-pipeline)), gebaut und eine Live-URL zurückgegeben. Nützliche Flags: + +| Flag | Zweck | +|------|---------| +| `-r, --repo ` | Quell-Repository | +| `-n, --name ` | Service-Name (verwendet in `${{name.KEY}}`-Refs und im Dashboard) | +| `-v, --variables ` | Eine Umgebungsvariable setzen; mehrfach verwendbar | +| `--region ` | Region für das Deployment | +| `--no-deploy` | Das Repo verbinden, aber den ersten Build überspringen | + +## Private Repositories + +Verbinde die Lizard GitHub App einmal pro Account, um Zugriff auf private Repos zu gewähren: + +```bash +lizard git connect +lizard git status # show connection + repo status +``` + +Du kannst den Repository-Zugriff auch auf der Seite **GitHub-Integration** im Dashboard verbinden und verwalten (`lizard open`). + + + +## Einen bestehenden Service auf ein Repo verweisen lassen + +Um einen Service auf eine Git-Quelle umzustellen (oder Repo/Branch zu ändern): + +```bash +lizard service set api \ + --set sourceType=github \ + --set repoUrl=https://github.com/your-org/your-app \ + --set branch=main +``` + +Das Ändern eines Build-Felds löst automatisch einen Rebuild aus — hänge danach **kein** `redeploy` an. + +> **Hinweis:** `lizard up` erzwingt immer `sourceType=upload`. Verwende es nicht, um einen Git-gestützten Service zu aktualisieren — pushe zum Remote oder verwende stattdessen `lizard redeploy`. + + + +## Automatische erneute Bereitstellung bei Push + +Sobald `repoUrl` gesetzt ist, lösen Pushes zum passenden `branch` über den GitHub-Webhook automatisch eine erneute Bereitstellung aus. Um festzulegen, welche Pushes eine erneute Bereitstellung auslösen: + +- **`rootDirectory`** — nur ein Unterverzeichnis bauen (Monorepos). +- **`watchPatterns`** — nur dann erneut bereitstellen, wenn passende Pfade geändert werden. + +```bash +lizard service set api --set watchPatterns='apps/api/**,packages/**' +``` + + + +## Branches wechseln + +```bash +lizard git checkout api staging # move the `api` service to the `staging` branch and redeploy +``` + +## Monorepos + +Für ein Repo, das mehrere Apps enthält, erstelle einen Service pro App und setze dessen `rootDirectory` auf den Unterpfad: + +```bash +lizard add -r your-org/monorepo -n api +lizard service set api --set rootDirectory=apps/api +``` + +Wenn dein aktuelles Verzeichnis eine Sub-App in einem Repo ist, dessen Elternverzeichnis bereits verknüpft ist, füge den Service im Projekt des Elternverzeichnisses hinzu und setze `rootDirectory` auf den Unterpfad des aktuellen Verzeichnisses. + + + +## Siehe auch + +- [Build-Pipeline](/concepts/build-pipeline) — wie dein Stack erkannt und gebaut wird. +- [Von lokalem Code deployen](/deploy/upload) — wenn du kein Remote hast. +- [`lizard git`](/cli/git) — die vollständige Befehlsreferenz für `connect`, `status` und `checkout`. +- [Wohin du eine App deployen solltest, die deine AI IDE gebaut hat](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#where-to-deploy-an-app-your-ai-ide-built) — wie du dies auf ein Repo verweist, das ein Agent geschrieben hat, und was es kostet. diff --git a/_locales/de/deploy/index.mdx b/_locales/de/deploy/index.mdx new file mode 100644 index 0000000..8d7907c --- /dev/null +++ b/_locales/de/deploy/index.mdx @@ -0,0 +1,22 @@ +--- +description: "Alles darüber, wie du einen Service auf Lizard zum Laufen bringst und dort hältst: GitHub- und lokale Deploys, Worker, Skalierung, Regionen und Fehlerbehebungen." +--- + + + +# Bereitstellen + +Alles darüber, wie du einen Service auf Lizard zum Laufen bringst und so betreibst — vom ersten Push bis zu Skalierung und Regionsplatzierung. + +Vergleichst du das zuerst mit einem anderen Host? Der Blog stellt die Preise von neun Plattformen für [container as a service](https://lizard.build/blog/container-as-a-service) direkt nebeneinander. + + + +## In diesem Abschnitt + +- [Bereitstellen von GitHub](/deploy/github) — verbinde ein Repo, damit Pushes auf den verfolgten Branch automatisch neu deployen. +- [Bereitstellen aus lokalem Code](/deploy/upload) — stelle das aktuelle Verzeichnis mit `lizard up` bereit, ganz ohne Git. +- [Background Workers](/deploy/workers) — führe Queue-Consumer und Polling-Schleifen mit `containerPort=0` aus. +- [Skalierung](/deploy/scaling) — passe Replikate, Ressourcen und Speicher an. +- [Regionen](/deploy/regions) — wo deine Services laufen. +- [Fehlerbehebung](/deploy/troubleshooting/incomplete-dockerfile) — Lösungen für die häufigsten Build- und Bereitstellen-Probleme. diff --git a/_locales/de/deploy/regions.mdx b/_locales/de/deploy/regions.mdx new file mode 100644 index 0000000..87b42c8 --- /dev/null +++ b/_locales/de/deploy/regions.mdx @@ -0,0 +1,40 @@ +--- +description: "Wählen Sie aus, wo Ihre Services und Addons laufen, platzieren Sie zustandsbehaftete Ressourcen gemeinsam, um die Latenz zu verringern, und sehen Sie, wie sich die Region auf generierte Domains auswirkt." +--- + + + +# Regionen + +Services und Addons werden in einer Region bereitgestellt. Listen Sie die für Ihr Konto verfügbaren Regionen auf und wählen Sie beim Erstellen eine aus. + + + +## Regionen auflisten + +```bash +lizard regions +lizard regions --json +``` + + + +## Eine Region auswählen + +Übergeben Sie `--region ` beim Erstellen eines Service oder Add-on: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +Wenn Sie keine Region angeben, verwendet die Plattform den Standard des Projekts. + +> **Zustandsbehaftete Ressourcen gemeinsam platzieren.** Platzieren Sie einen Service und die Addons, mit denen er kommuniziert (Postgres, Redis, S3), in **derselben Region**, um die Latenz niedrig zu halten und regionenübergreifende Datengebühren zu vermeiden. + + + +## Generierte Domains + +Jeder Service erhält unabhängig von der Region eine generierte Domain auf `*.onlizard.com` mit automatischem TLS. Object Storage, das von einem [S3-Add-on](/addons/storage) bereitgestellt wird, verwendet einen regionsspezifischen Gateway-Host (`s3-.onlizard.com`). Informationen zum Zuweisen Ihres eigenen Hostnamens finden Sie unter [Networking](/networking). diff --git a/_locales/de/deploy/scaling.mdx b/_locales/de/deploy/scaling.mdx new file mode 100644 index 0000000..0e95d2e --- /dev/null +++ b/_locales/de/deploy/scaling.mdx @@ -0,0 +1,78 @@ +--- +description: "Fügen Sie Replikate hinzu oder erhöhen Sie CPU und Arbeitsspeicher für einen Service und erweitern Sie den Add-on-Speicher. Zulässige Bereiche, Rollout-Verhalten und wie Sie eine Änderung prüfen." +--- + + + +# Skalierung + +Skalieren Sie einen Service horizontal (mehr Replikate) oder vertikal (mehr CPU/Arbeitsspeicher) mit `lizard scale`. Add-on-Speicher wird auf die gleiche Weise erweitert. + + + +## Einen Service skalieren + +```bash +lizard scale --service api --replicas 3 +lizard scale --service api --cpu 2 --memory 2048 +``` + +| Flag | Gilt für | Zulässige Werte | +|------|-----------|----------------| +| `--replicas ` | Apps | `1`–`10` | +| `--cpu ` | Apps | ganze Kerne: `1`, `2`, `3`, `4` | +| `--memory ` | Apps | `128`–`8192` MB (in 1-MB-Schritten) | +| `--storage ` | **nur Addons**, nur vergrößern | `512`, `1024`, `2048`, `4096`, `8192`, `16384` | + +Sie können Flags in einem einzelnen Befehl kombinieren. Änderungen an Replikaten werden ohne Rebuild ausgerollt. + + + +## Horizontale Skalierung + +Führen Sie mehrere Replikate einer App hinter dem Load Balancer aus: + +```bash +lizard scale --service api --replicas 5 +``` + +Jedes Replikat ist ein eigener Pod. Stellen Sie sicher, dass Ihre App zustandslos ist (speichern Sie den Zustand in [Postgres](/addons/postgres), [Redis](/addons/redis) oder [S3](/addons/storage)), damit Replikate austauschbar sind. + + + +## Vertikale Skalierung + +Geben Sie einem einzelnen Replikat mehr Ressourcen: + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +## Add-on-Speicher erweitern + +Add-on-Daten-Volumes können **nur vergrößert** werden — Sie können den Speicher erhöhen, aber nicht verkleinern: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Prüfung + +```bash +lizard ps # replica status + URL +lizard events # per-replica deploy/scale history +lizard metrics # live CPU / memory / network / disk +lizard metrics --cost # include cost +``` + + + +## Siehe auch + +- [Observability → Metrics](/observability/metrics) — Ressourcen- und Kostenüberwachung. +- [`lizard scale`](/cli/scale) — die vollständige Befehlsreferenz. +- [Was CaaS-Anbieter 2026 berechnen](https://lizard.build/blog/container-as-a-service#what-caas-providers-charge-in-2026) — Preise pro vCPU, pro GB und für Egress über neun Plattformen hinweg, um eine Rechnung abzuschätzen, bevor Sie skalieren. diff --git a/_locales/de/deploy/troubleshooting/_meta.ts b/_locales/de/deploy/troubleshooting/_meta.ts new file mode 100644 index 0000000..9fa76a9 --- /dev/null +++ b/_locales/de/deploy/troubleshooting/_meta.ts @@ -0,0 +1,5 @@ +export default { + 'incomplete-dockerfile': "Änderungen an der Dockerfile werden nicht übernommen", + 'double-build': "Eine Änderung hat zwei Builds in die Warteschlange gestellt", + 'service-never-healthy': "Der Service wird nie als fehlerfrei eingestuft", +}; diff --git a/_locales/de/deploy/troubleshooting/double-build.mdx b/_locales/de/deploy/troubleshooting/double-build.mdx new file mode 100644 index 0000000..a6bf52c --- /dev/null +++ b/_locales/de/deploy/troubleshooting/double-build.mdx @@ -0,0 +1,53 @@ +--- +description: "Warum lizard service set, gefolgt von einem Redeploy, zwei Builds in die Warteschlange stellt, welche Felder selbstständig neu bauen und wie du den überflüssigen Build vermeidest." +--- + + + +# Meine Änderung hat zwei Builds direkt hintereinander in die Warteschlange gestellt + +Du hast `lizard service set` ausgeführt, um ein Feld zu ändern, dann `lizard redeploy`, und am Ende wurden zwei Builds statt nur eines gestartet. + + + +## Was das bedeutet + +Der Aufruf `service set` hat bereits selbstständig einen Rebuild ausgelöst. Das anschließende `redeploy` hat einen zweiten, überflüssigen Build in die Warteschlange gestellt. + + + +## Warum das passieren kann + +Wenn du ein **build-relevantes** Feld eines Service änderst — `repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath` oder `rootDirectory` — wird sofort automatisch ein Rebuild ausgelöst. Wenn du ein **reines Laufzeitfeld** änderst — `startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns` — wird **kein** automatischer Rebuild ausgelöst; die Änderung wird erst beim nächsten Bereitstellen wirksam. + +Es ist leicht, reflexartig nach jedem `service set` noch ein `redeploy` anzuhängen, aber das ist nur bei reinen Laufzeitfeldern sinnvoll. + + + +## Mögliche Lösungen + + + +### Prüfe, welche Art von Feld du geändert hast + +Sieh in der [Tabelle der Rebuild-Auslöser](/concepts/build-pipeline#what-triggers-a-rebuild) nach. Wenn es ein Build-Feld ist, ist der Rebuild bereits in der Warteschlange — du musst nichts weiter tun. + +```bash +lizard events # confirm only one build is in flight +``` + + + +### Nur nach Änderungen an reinen Laufzeitfeldern neu deployen + +```bash +lizard service set api --set startCommand="node server.js" +lizard redeploy --service api # needed here — startCommand doesn't auto-rebuild +``` + + + +## Siehe auch + +- [Build-Pipeline → was einen Rebuild auslöst](/concepts/build-pipeline#what-triggers-a-rebuild) +- [`lizard service`](/cli/service) — die vollständige Befehlsreferenz. diff --git a/_locales/de/deploy/troubleshooting/incomplete-dockerfile.mdx b/_locales/de/deploy/troubleshooting/incomplete-dockerfile.mdx new file mode 100644 index 0000000..6c75a7e --- /dev/null +++ b/_locales/de/deploy/troubleshooting/incomplete-dockerfile.mdx @@ -0,0 +1,57 @@ +--- +description: "Warum Lizard ein Dockerfile im Repo ohne Build-Schritt ersetzt, wie die Regel für unvollständige Dockerfiles funktioniert und wie Ihres unverändert verwendet wird." +--- + + + +# Meine Dockerfile-Änderungen scheinen nicht angewendet zu werden + +Sie haben ein `Dockerfile` in Ihrem Repo, Sie haben es bearbeitet, aber der Build, den Lizard ausführt, entspricht nicht dem, was Sie geschrieben haben. + + + +## Was das bedeutet + +Die Plattform hat entschieden, dass das Dockerfile Ihres Repos **unvollständig** war, und mit [lizardpack](/concepts/build-pipeline) stattdessen eines für Sie neu erzeugt, anstatt Ihres unverändert zu verwenden. + + + +## Warum das passieren kann + +Lizard verwendet ein Dockerfile aus dem Repo im lizardpack-Autoerkennungspfad nur dann **unverändert**, wenn es einen echten Build-Schritt hat — eine Zeile `RUN `. Ein Dockerfile, das nur vorab gebaute Artefakte kopiert (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) und keinen Schritt `RUN` enthält, wird als unvollständig behandelt, in der Annahme, dass diese Artefakte außerhalb des Images gebaut wurden. In diesem Fall erzeugt lizardpack ein Ersatz-Dockerfile, das den fehlenden Build-Schritt enthält. + +Das gilt nur auf dem lizardpack-Autoerkennungspfad. Wenn `buildCommand` oder `startCommand` für den Service gesetzt ist, erzeugt Lizard stattdessen aus diesen Befehlen ein Dockerfile und berücksichtigt das Dockerfile Ihres Repos überhaupt nicht. + + + +## Mögliche Lösungen + + + +### Einen echten Build-Schritt hinzufügen + +Wenn Sie möchten, dass Ihr Dockerfile unverändert verwendet wird, geben Sie ihm einen tatsächlichen Build-Schritt, anstatt vorab gebaute Ausgaben zu kopieren: + +```dockerfile +RUN npm ci && npm run build +``` + + + +### Oder die unveränderte Verwendung erzwingen + +Entfernen Sie Build- und Start-Overrides und setzen Sie dann im selben Update `dockerfilePath`. Overrides haben Vorrang vor dem Dateipfad: + +```bash +lizard service set api --set buildCommand=null --set startCommand=null --set dockerfilePath=Dockerfile +``` + + + +## Siehe auch + +- [Build-Pipeline](/concepts/build-pipeline) — die vollständige Reihenfolge der Build-Entscheidungen. +- [Referenz zur Build-Konfiguration](/concepts/build-pipeline#build-configuration-reference) +- [Beliebige Python-App auf Lizard deployen](https://lizard.build/blog/python-app-hosting#deploying-any-python-app-on-lizard) — wann Sie lizardpack das Dockerfile schreiben lassen sollten und wann Sie Ihr eigenes mitbringen. + +Das Ändern dieser Build-Felder kann einen Build starten. Prüfen Sie `lizard events`, bevor Sie ein weiteres `redeploy` senden, um zu vermeiden, einen zweiten Build zu starten. diff --git a/_locales/de/deploy/troubleshooting/service-never-healthy.mdx b/_locales/de/deploy/troubleshooting/service-never-healthy.mdx new file mode 100644 index 0000000..8fbfc57 --- /dev/null +++ b/_locales/de/deploy/troubleshooting/service-never-healthy.mdx @@ -0,0 +1,59 @@ +--- +description: "Ein Build ist erfolgreich, aber der Bereitstellen bleibt ungesund. Port-Binding, versehentlicher Worker-Modus und weitere Ursachen für einen fehlschlagenden Health-Checks." +--- + + + +# Mein Service wird deployt, wird aber nie healthy + +Der Build ist erfolgreich, Replikate starten, aber der Bereitstellen bleibt ausstehend, wird als ungesund markiert oder erhält nie Traffic. + + + +## Was das bedeutet + +Der Health-Checks der Plattform — der prüft, ob der Port deiner App erreichbar ist — schlägt nie an, daher wird der Traffic nie auf die neuen Replikate umgeschaltet. + + + +## Warum das passieren kann + +- **Deine App lauscht nicht auf dem erwarteten Port.** Lizard setzt eine `PORT`-Umgebungsvariable (Standard-Container-Port `3000`) und prüft, ob deine App dort erreichbar ist. Wenn deine App fest auf einen anderen Port eingestellt ist oder nie einen Port bindet, schlägt der Health-Checks unbegrenzt fehl. Ein Python-App ist der übliche Fall: `gunicorn` und `uvicorn` binden an `127.0.0.1`, sofern du nichts anderes angibst, und die Probe kommt von außerhalb des Prozesses. [Python-App-Hosting](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) enthält die Zeile `--bind 0.0.0.0:$PORT`, die jedes Framework braucht. +- **Der Service ist versehentlich im Worker-Modus.** Das Setzen von `containerPort=0` versetzt einen Service in den [Worker-Modus](/deploy/workers), wodurch **der Health-Checks und die Registrierung beim Load Balancer vollständig übersprungen werden**. Ein Service, der eigentlich HTTP bereitstellen soll, aber auf `containerPort=0` umgestellt wurde, wird "erfolgreich" deployt und liefert dann einfach nie etwas aus — der Worker-Modus verdeckt das zugrunde liegende Startproblem, statt es sichtbar zu machen. + + + +## Mögliche Lösungen + + + +### Den aktuellen Port prüfen + +```bash +lizard port --service api +``` + +Wenn hier `worker mode` ausgegeben wird, hat der Service `containerPort=0`. Setze ihn wieder auf einen echten Port zurück, wenn dieser Service HTTP bereitstellen soll: + +```bash +lizard port 3000 --service api +lizard redeploy --service api +``` + + + +### Bestätigen, dass deine App dort lauscht, wo Lizard es erwartet + +Prüfe die Runtime-Logs auf Startfehler und vergleiche den Port, an den die App tatsächlich gebunden wurde, mit dem, was Lizard gesetzt hat: + +```bash +lizard logs --service api +lizard ssh --service api -- env | grep PORT +``` + + + +## Siehe auch + +- [Background Workers](/deploy/workers) — wann `containerPort=0` sinnvoll ist (und wann nicht). +- [Bereitstellungen → lifecycle](/concepts/deployments#lifecycle) — wo der Health-Checks innerhalb eines Deploys stattfindet. diff --git a/_locales/de/deploy/upload.mdx b/_locales/de/deploy/upload.mdx new file mode 100644 index 0000000..39d0366 --- /dev/null +++ b/_locales/de/deploy/upload.mdx @@ -0,0 +1,82 @@ +--- +description: "Stelle das aktuelle Verzeichnis mit lizard up bereit, ganz ohne Git. Behandelt gitignore, Build- und Start-Overrides sowie die Nutzung in headless CI." +--- + + + +# Bereitstellung aus lokalem Code + +Wenn dein Code nicht auf GitHub liegt — oder du einfach schnell iterieren willst — lade das aktuelle Verzeichnis direkt mit `lizard up` hoch. Dabei wird dein Arbeitsverzeichnis als Tarball gepackt, an die Build-Knoten gesendet und bereitgestellt. + + + +## Das aktuelle Verzeichnis bereitstellen + +```bash +lizard up +``` + +- Lädt das aktuelle Verzeichnis als Tarball hoch und beachtet dabei `.gitignore` (deaktivierbar mit `--no-gitignore`). +- Erzwingt `sourceType=upload`. +- Streamt Build-Logs über SSE und gibt nach Abschluss die Live-URL aus. + +Wenn das Verzeichnis noch nicht mit einem Projekt verknüpft ist, führt `up` zuerst `init` aus. In einem TTY ist das interaktiv; in einem non-TTY (CI) wird **nicht** stillschweigend ein Projekt erstellt — stattdessen gibt es einen Fehler und die Aufforderung, `lizard init --name ` auszuführen (oder `--name` zu übergeben). Das schützt davor, dass ein Tippfehler ein leeres Projekt erzeugt. + + + +## Häufige Flags + +| Flag | Zweck | +|------|---------| +| `-s, --service ` | Einen bestimmten Service ansprechen/erstellen | +| `--build-command ` | Den Build-Befehl überschreiben | +| `--start-command ` | Den Start-Befehl überschreiben | +| `--pre-deploy-command ` | Vor jeder Bereitstellung einmal ausführen (z. B. Migrationen) | +| `--port ` | Container-Port (`0` = [Worker-Modus](/deploy/workers)) | +| `--region ` | Region für die Bereitstellung | +| `-d, --detach` | Bereitstellung starten und beenden, ohne Logs zu streamen | +| `-c, --ci` | CI-freundliche Ausgabe | +| `--no-gitignore` | Alles hochladen und `.gitignore` ignorieren | + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +## Build-/Start-Befehle festlegen + +Wenn du `--build-command` oder `--start-command` übergibst, wechselt der Service auf den Pfad mit dem **synthetisierten Dockerfile**. Auf diesem Pfad werden `Procfile` und `package.json` `scripts.start` **nicht** gelesen — setze den Start-Befehl daher explizit (oder füge ein `CMD` in dein eigenes Dockerfile ein). Siehe [Build-Pipeline](/concepts/build-pipeline). Besonders oft tritt das bei Python auf: [Django, Flask und FastAPI](https://lizard.build/blog/python-app-hosting#deploying-django) benötigen jeweils eine andere Zeile für `gunicorn` oder `uvicorn`. + + + +## Einen Upload-Service erneut bereitstellen + +`lizard up` lädt erneut hoch und baut neu. Um den **letzten** Upload mit den aktuellen Variablen neu zu bauen, ohne erneut hochzuladen: + +```bash +lizard redeploy --service api +``` + +## Headless / CI + +Für nicht interaktive Abläufe verknüpfe das Projekt vor der Bereitstellung ausdrücklich: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +## Wann GitHub stattdessen besser ist + +Upload eignet sich hervorragend für schnelle Iterationen und Situationen ohne Remote. Für alles, was langfristig läuft, ist eine [GitHub-Quelle](/deploy/github) die bessere Wahl, damit Pushes automatisch neu bereitgestellt werden und du eine saubere Bereitstellungshistorie erhältst. + + + +## Siehe auch + +- [`lizard up`](/cli/up) — die vollständige Befehlsreferenz. +- [Build-Pipeline](/concepts/build-pipeline) — wie dein Stack erkannt und gebaut wird. diff --git a/_locales/de/deploy/workers.mdx b/_locales/de/deploy/workers.mdx new file mode 100644 index 0000000..3807c77 --- /dev/null +++ b/_locales/de/deploy/workers.mdx @@ -0,0 +1,124 @@ +--- +description: "Führen Sie Queue-Consumer und Polling-Schleifen ohne HTTP-Port aus. Was containerPort=0 ändert, wie Sie den Worker-Modus aktivieren und wann Sie ihn nicht verwenden sollten." +--- + + + +# Hintergrund-Worker + +Nicht jeder Dienst stellt HTTP bereit. Queue-Consumer, Reconciler, Cron-artige Polling-Schleifen und andere Hintergrund-Workloads lauschen nicht auf einem Port — führen Sie sie im **Worker-Modus** aus, indem Sie den Container-Port auf `0` setzen. + + + +## Was der Worker-Modus ändert + +Wenn `containerPort=0`, macht die Plattform Folgendes: + +- **Überspringt die `PORT`-Injektion** — der Worker bindet nirgendwo. +- **Überspringt die Erreichbarkeitsprüfung des Ports** — kein `app port X unreachable`-Log-Spam und kein falsch-positiver Status „unhealthy“. +- **Überspringt `EXPOSE`** im erzeugten Dockerfile. +- **Überspringt die Registrierung von Load-Balancer-Routen** — es wird nichts bereitgestellt. (Eine generierte `*.onlizard.com`-Domain kann beim Dienst dennoch erscheinen, antwortet aber nicht.) + + + +## Worker-Modus aktivieren + +Drei gleichwertige Möglichkeiten: + +```bash +# New upload-source worker +lizard up --port 0 + +# Flip an existing service +lizard port 0 --service worker + +# Via the config:apply path +lizard service set worker --set containerPort=0 +``` + +Der Worker-Modus ist eine harte Umschaltung — ein Redeploy ist erforderlich, damit die Port-Änderung wirksam wird. + + + +## Den aktuellen Port prüfen + +```bash +lizard port --service worker +``` + +Gibt den aktuellen Container-Port aus, oder `worker mode`, wenn er `0` ist. + + + +## Wann Sie den Worker-Modus *nicht* verwenden sollten + +Verwenden Sie den Worker-Modus nicht für einen normalen HTTP-Dienst, der nur langsam startet. Der Worker-Modus deaktiviert die Erreichbarkeitsprüfung vollständig und wird dadurch Fehler **verbergen** wie „der Listener ist nie hochgekommen“. Wenn Ihr Dienst Traffic bedienen soll, behalten Sie einen echten Port bei und beheben Sie stattdessen den Startvorgang. + + + +## Einen Queue-Consumer ausführen + +Verwenden Sie das Beispiel [redis-worker](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/redis-worker). Es verschiebt einen Job aus einer Pending-Liste in eine Processing-Liste, speichert sein Ergebnis in Großbuchstaben und bestätigt den Job in einer Redis-Transaktion. Behalten Sie ein Replikat bei: Die Wiederherstellung beim Start geht von einem einzelnen Consumer aus. Das Beispiel verwendet Python 3.13 und redis-py 6.4.0. + +Aus dem Verzeichnis mit dem Dockerfile: + +```bash +lizard init --name queue-example +lizard add --service worker +lizard add redis +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +lizard up --service worker --port 0 +``` + +Melden Sie sich mit `lizard login` an, wenn ein Befehl meldet, dass eine Authentifizierung erforderlich ist. Verwenden Sie den tatsächlichen Namen der Datenbank, falls er nicht `redis` ist. Lassen Sie die Referenz in Anführungszeichen. Setzen Sie sie, bevor Sie die Anwendung hochladen. Unter macOS mit Lizard CLI 0.3.92 stellen Sie `lizard up` `COPYFILE_DISABLE=1` voran, um AppleDouble-Metadaten auszuschließen. + +Prüfen Sie das letzte Bereitstellen-Ereignis und dann den Worker: + +```bash +lizard port --service worker +lizard logs --service worker --json +lizard ssh --service worker -- python jobs.py enqueue first-job +lizard ssh --service worker -- python jobs.py result first-job +``` + +Der Prozess gibt `Queue worker ready` aus. Wenn das Log-Tail leer ist, fahren Sie mit der untenstehenden Job-Prüfung fort; die [Testergebnisse](/guides/validation) dokumentieren das beobachtete Logging-Limit. Der Ergebnisbefehl wartet bis zu 30 Sekunden und gibt `{"id": "first-job", "result": "HELLO"}` aus. Ein laufender Prozess allein beweist nicht, dass er einen Job verarbeiten kann. Managed Redis wird aus dem Dienst heraus erreicht; der CLI-Befehl setzt nicht voraus, dass Ihr Laptop seine private Adresse erreichen kann. + + + +## Einen Neustart prüfen + +Für diesen Testdienst starten Sie den Worker neu und senden einen weiteren Job ab: + +```bash +lizard restart --service worker +lizard ssh --service worker -- python jobs.py result first-job +lizard ssh --service worker -- python jobs.py enqueue after-restart +lizard ssh --service worker -- python jobs.py result after-restart +``` + +Warten Sie, bis der Dienst wieder `running` in `lizard ps --json` meldet, falls SSH noch nicht verfügbar ist. Beide Ergebnisse sollten `HELLO` sein. Das erste Ergebnis liegt in Redis, daher entfernt ein Worker-Neustart es nicht. Beim Start verschiebt der einzelne Consumer nicht abgeschlossene Processing-Einträge zurück in die Pending-Liste. + +Diese Demo akzeptiert nur die JSON-Jobs, die von `jobs.py` erstellt werden. Sie implementiert weder eine Dead-Letter-Queue noch eine Validierung für nicht vertrauenswürdige Producer oder Exactly-once-Nebeneffekte nach außen. Verwenden Sie für Zahlungen, E-Mails oder andere Effekte eine etablierte Queue-Bibliothek und idempotente Handler. Redis-Dauerhaftigkeit und Backups sind getrennt vom Verhalten bei Worker-Neustarts zu betrachten; siehe [Speicherung und Wiederherstellung](/platform/storage-and-recovery). + + + +## Fehlerbehebung + +| Symptom | Prüfung | +|---|---| +| Fehlender Dienst | Führen Sie nach dem Erstellen des Projekts `lizard add --service worker` aus. | +| Kein `Queue worker ready` | Prüfen Sie das dienstbezogene `REDIS_URL`, die Bereitschaft des Add-ons und Verbindungsfehler. Geben Sie niemals den Connection String aus. | +| Worker erwartet einen HTTP-Port | Setzen Sie `containerPort=0`; das Ändern bei einem laufenden Dienst erfordert ein Redeploy. | +| Kein Ergebnis nach 30 Sekunden | Lesen Sie die Worker-Logs und prüfen Sie die Job-ID. Dieses Beispiel akzeptiert nur Jobs aus seinem eigenen `jobs.py`. | +| Doppelte Effekte | Ein Retry kann Arbeit erneut ausführen. Dieses Beispiel speichert ein Ergebnis nach Job-ID; externe Effekte benötigen eine eigene Idempotenz. | + + + +## Siehe auch + +- [`lizard port`](/cli/port) — Container-Port eines Dienstes anzeigen oder ändern. +- [Dienst wird nie healthy](/deploy/troubleshooting/service-never-healthy) — die häufigste Fehlkonfiguration im Worker-Modus. +- [Managed Addons](/addons) — Redis, Postgres und S3 für zustandsbehaftete Workloads. +- [Python-App-Hosting](https://lizard.build/blog/python-app-hosting#deploying-django) — ein Celery-Worker ist dasselbe Image mit einem anderen Befehl und ohne HTTP-Port. + +Siehe [Testergebnisse zum Szenario](/guides/validation) für geprüfte Versionen, Cloud-Ergebnisse und verbleibende Einschränkungen. diff --git a/_locales/de/framework-guides/_meta.ts b/_locales/de/framework-guides/_meta.ts new file mode 100644 index 0000000..13b1f0c --- /dev/null +++ b/_locales/de/framework-guides/_meta.ts @@ -0,0 +1,16 @@ +export default { + index: "Überblick", + nextjs: { title: "Next.js", display: "children" }, + react: "React (Vite)", + vue: "Vue (Vite)", + astro: "Astro", + nuxt: "Nuxt", + sveltekit: "SvelteKit", + fastapi: "FastAPI", + django: "Django", + docusaurus: "Docusaurus", + vitepress: "VitePress", + hugo: "Hugo", + 'static-routing': "Statische Routen & 404-Seiten", + validation: "Getestete Versionen & Ergebnisse", +}; diff --git a/_locales/de/framework-guides/astro.mdx b/_locales/de/framework-guides/astro.mdx new file mode 100644 index 0000000..4111316 --- /dev/null +++ b/_locales/de/framework-guides/astro.mdx @@ -0,0 +1,98 @@ +--- +description: "Stelle Astro auf Lizard als statische Website oder mit dem eigenständigen Node-Adapter bereit. Konfiguriere output, Build-Befehle, Ports und Prüfungen für Serverrouten und fehlende Seiten." +--- + + + +# Astro auf Lizard bereitstellen + +Astro hat auf Lizard zwei Bereitstellungswege: ein statisches Verzeichnis `dist/` auf Port `80` bereitstellen oder den eigenständigen Node-Adapter auf Port `3000` für bedarfsgesteuerte Routen ausführen. Wähle den Modus vor dem Deployment, weil der Adapter sowohl die Ausgabe als auch die Laufzeitumgebung verändert. + + + +## Modus wählen + +| Modus | Konfiguration | Laufzeitumgebung | Port | +|---|---|---|---| +| Statische Website | Statische Ausgabe ohne Server-Adapter | nginx stellt `dist/` bereit | `80` | +| Node-Server | `@astrojs/node` im Standalone-Modus | `node ./dist/server/entry.mjs` | `3000` | + +Beide Wege verwenden ein `build`-Skript, das `astro build` ausführt. Committe die Lockfile und behalte den standardmäßigen Ausgabepfad `dist` bei. Die Erkennung liest die Astro-Konfiguration und installierte Abhängigkeiten. Eine ungenutzte Node-Adapter-Abhängigkeit allein wählt den Serverpfad nicht aus. Verwende literales `output` und Adapter-Einstellungen; dynamische Werte, benutzerdefinierte Ausgabepfade und Middleware-Modus benötigen ein Dockerfile. + + + +## Einen Node-Server konfigurieren + +Für bedarfsgesteuerte Seiten füge eine Node-Adapter-Version hinzu, die mit deiner Astro-Version kompatibel ist: + +```bash +npx astro add node +``` + +Prüfe `astro.config.mjs`: + +```js +import { defineConfig } from 'astro/config'; +import node from '@astrojs/node'; + +export default defineConfig({ + output: 'server', + adapter: node({ mode: 'standalone' }), +}); +``` + +Der Standalone-Modus startet seinen eigenen HTTP-Server. Der Middleware-Modus erfordert einen separaten Server und passt nicht zu diesem Startbefehl. Lies den [Astro Node Adapter Anleitung](https://docs.astro.build/en/guides/integrations-guide/node/), wenn du Middleware oder eine Mischung aus vorgerenderten und bedarfsgesteuerten Routen brauchst. + + + +## Lokal testen + +```bash +npm ci +npm run build +``` + +Für den Node-Modus: + +```bash +HOST=0.0.0.0 PORT=3000 node ./dist/server/entry.mjs +``` + +Rufe eine Route auf, die tatsächlich auf dem Server ausgeführt wird, und ein gebautes Asset. Für eine statische Website verwende lokal `npm run preview` und prüfe die generierten Routendateien in `dist/`. + + + +## Bereitstellen + +Erstelle nach dem [CLI-Setup](/framework-guides#prepare-the-project) das Projekt: + +```bash +lizard init --name astro-app +lizard add --service web +``` + +Für den Node-Adapter: + +```bash +lizard up --service web --port 3000 +``` + +Für eine statische Website: + +```bash +lizard up --service web --port 80 +``` + +Verwende nur den Befehl für den gewählten Modus. Lass Überschreibungen des Service-Befehls für die lizardpack-Erkennung ungesetzt. Lies `lizard logs --build --service web --json` und prüfe dann die Laufzeitprotokolle und die Live-URL. + + + +## Variablen, Sessions und Routen + +Werte, die zum Erzeugen von statischem HTML verwendet werden, erfordern einen neuen Build, wenn sie sich ändern. Servercode kann Laufzeitvariablen über die von deiner Astro-Version unterstützten Mechanismen lesen; konfiguriere sie unter [Variablen und Secrets](/variables). Im Browser sichtbare Werte dürfen keine Zugangsdaten enthalten. + +Wenn deine App Sessions verwendet, wähle einen Speicher, der zu Neustarts und mehreren Replikaten passt. Verlasse dich nicht auf das Container-Dateisystem als gemeinsamen dauerhaften Speicher. Siehe [Storage und Wiederherstellung](/platform/storage-and-recovery). + +Teste bei einer Website mit statischen Inhalten eine fehlende URL und verwende [statische Routen und 404-Seiten](/framework-guides/static-routing), um den korrekten Status zurückzugeben. Wenn ein SSR-Deployment beendet wird oder keine Routen bereitstellt, prüfe, dass `dist/server/entry.mjs` existiert, der Adapter den Standalone-Modus verwendet und der Service-Port `3000` ist. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Deployment-Prüfungen vom 9. September 2026 und deren Grenzen. diff --git a/_locales/de/framework-guides/django.mdx b/_locales/de/framework-guides/django.mdx new file mode 100644 index 0000000..081007c --- /dev/null +++ b/_locales/de/framework-guides/django.mdx @@ -0,0 +1,221 @@ +--- +description: "Stelle Django auf Lizard mit Gunicorn, einem expliziten WSGI-Modul, Port 8000, Produktionseinstellungen, Datenbankmigrationen und einem Plan für statische sowie hochgeladene Dateien bereit." +--- + + + +# Django auf Lizard bereitstellen + +Führe Django auf Lizard mit Gunicorn und dem WSGI-Modul deines Projekts auf Port `8000` aus. Bereite Produktionseinstellungen, Datenbankzugriff und die Bereitstellung statischer Dateien vor, bevor du dich auf die bereitgestellte App verlässt. `manage.py runserver` ist ein Entwicklungsserver. + + + +## Startbefehl festlegen + +Diese Anleitung setzt `manage.py`, `requirements.txt` und ein Projektpaket namens `config` voraus, das `wsgi.py` enthält. Ersetze `config` durch deinen tatsächlichen Paketnamen. + +Nimm Django, Gunicorn und den Datenbanktreiber, den deine App verwendet, in deine getesteten Anforderungen auf. Füge ein `Procfile` hinzu: + +```text +web: gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +Das explizite Modul vermeidet Unklarheiten, wenn Einstellungen in verschachtelten Paketen liegen. Eine ASGI-App mit WebSockets benötigt einen ASGI-Server und einen anderen Startbefehl; diese Anleitung behandelt WSGI. + +| Einstellung | Wert | +|---|---| +| Installation | `pip install -r requirements.txt` | +| Laufzeit | Gunicorn mit deinem WSGI-Modul | +| Service-Port | `8000` | +| Arbeitsverzeichnis | Verzeichnis, das `manage.py` enthält | + + + +## Produktionseinstellungen vorbereiten + +Django erwartet ein `DATABASES`-Wörterbuch in `settings.py`. Wenn du `DATABASE_URL` nur für den Service setzt, verbindet das Django nicht mit PostgreSQL. Die folgenden Schritte erstellen [Managed Postgres](/addons/postgres), übergeben seine URL an die App und wandeln diese URL in Djangos Verbindungseinstellungen um. + +Füge diese Pakete zu `requirements.txt` hinzu und behalte alle weiteren Abhängigkeiten bei, die deine App benötigt. Dies sind die Versionen, die im [vollständigen Beispiel](https://github.com/lizard-build/docs/tree/main/_examples/django) verwendet werden: + +```text +Django==6.1.1 +gunicorn==26.2.0 +whitenoise==6.12.0 +psycopg[binary]==3.3.5 +dj-database-url==3.1.2 +``` + +`psycopg` ist der PostgreSQL-Treiber. `dj-database-url` liest Datenbankname, Benutzer, Passwort, Host und Port aus der Verbindungs-URL. Ersetze die entsprechenden Einstellungen in der `settings.py` deines Projekts durch diesen Block; behalte deine vorhandenen Apps, Middleware, Vorlagen und weiteren Einstellungen bei: + +```python +import os +from pathlib import Path + +import dj_database_url +from django.core.exceptions import ImproperlyConfigured + +BASE_DIR = Path(__file__).resolve().parent.parent + + +def required_env(name): + value = os.environ.get(name, "").strip() + if not value: + raise ImproperlyConfigured(f"Set the {name} environment variable.") + return value + + +def env_list(name): + values = [item.strip() for item in required_env(name).split(",") if item.strip()] + if not values: + raise ImproperlyConfigured(f"Set at least one value in {name}.") + return values + + +SECRET_KEY = required_env("SECRET_KEY") +debug_value = os.environ.get("DEBUG", "false").strip().lower() +if debug_value not in {"true", "false"}: + raise ImproperlyConfigured("DEBUG must be true or false.") +DEBUG = debug_value == "true" +ALLOWED_HOSTS = env_list("ALLOWED_HOSTS") +CSRF_TRUSTED_ORIGINS = env_list("CSRF_TRUSTED_ORIGINS") +DATABASES = { + "default": dj_database_url.parse( + required_env("DATABASE_URL"), + conn_max_age=60, + conn_health_checks=True, + ) +} +``` + +Lass keine ältere Zuweisung für `DATABASES`, `SECRET_KEY` oder `DEBUG` weiter unten in der Datei stehen: Sie würde diese Werte überschreiben. Dieses Beispiel erfordert nichtleere Werte für `SECRET_KEY`, `DATABASE_URL`, `ALLOWED_HOSTS` und `CSRF_TRUSTED_ORIGINS`. Fehlende oder leere Werte stoppen den Start mit dem Namen der Variablen. `DEBUG` ist standardmäßig `false`; setze es im bereitgestellten Service auf `false`. + +`ALLOWED_HOSTS` akzeptiert kommagetrennte Hostnamen ohne Schema oder Pfad, zum Beispiel `app.example.com,www.example.com`. `CSRF_TRUSTED_ORIGINS` akzeptiert kommagetrennte Origins mit Schema, zum Beispiel `https://app.example.com`. Gib bei lokalen Origins einen Port an, wenn einer verwendet wird. Das Beispiel erfordert eine explizite Origin-Liste; Django selbst erlaubt eine leere Liste für Apps, die keine zusätzlichen vertrauenswürdigen Origins benötigen. Vertraue nur Origins, die Formulare an diese App senden sollen. Diese Einstellungen ersetzen keine CSRF-Tokens. + +Die URL stammt aus einem [Secret oder einer Referenz](/variables) des Service, nicht aus einem im Quellcode gespeicherten Wert. Verwende kein containerlokales SQLite als dauerhafte Datenbank für eine bereitgestellte App. Siehe [Verwendung von dj-database-url](https://pypi.org/project/dj-database-url/) für das Parsen von URLs und Verbindungsoptionen. + +Wenn deine lokalen Umgebungsvariablen gesetzt sind und PostgreSQL erreichbar ist, führe aus: + +```bash +python -m pip install -r requirements.txt +python manage.py check --deploy +gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +Prüfe Djangos [Deployment-Checkliste](https://docs.djangoproject.com/en/6.1/howto/deployment/checklist/) auf Einstellungen, die für deine App relevant sind. Das kleine Beispiel konfiguriert nicht jede Produktionseinstellung für Sicherheit. Prüfe Proxy- und HTTPS-Verhalten mit der tatsächlichen öffentlichen URL, bevor du sichere Cookies, HSTS oder Weiterleitungen aktivierst. Vertraue weitergeleiteten HTTPS-Headern nur, wenn der Proxy sie kontrolliert. + + + +## Statische Dateien und Migrationen planen + +Gunicorn allein stellt Djangos statische Dateien nicht bereit. Wähle entweder für die App konfigurierte Static-File-Middleware oder einen separaten Host für statische Dateien. Sammle Assets in den Pfad, den das Setup bereitstellt. Der Python-Pfad von lizardpack auf Basis von Requirements führt `collectstatic` nicht automatisch aus; füge ihn in einen vollständigen Dockerfile-Build ein, wenn die App diesen Schritt benötigt. + +Für WhiteNoise belasse `django.contrib.staticfiles` in `INSTALLED_APPS` und füge `whitenoise.middleware.WhiteNoiseMiddleware` direkt nach Djangos `SecurityMiddleware` ein. Füge diese Einstellungen hinzu oder aktualisiere sie: + +```python +STATIC_URL = "/static/" +STATIC_ROOT = BASE_DIR / "staticfiles" +STORAGES = { + "default": {"BACKEND": "django.core.files.storage.FileSystemStorage"}, + "staticfiles": { + "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage", + }, +} +``` + +Behalte dein vorhandenes Backend für `STORAGES["default"]` bei, wenn die App Uploads bereits woanders speichert. WhiteNoise stellt gesammelte statische Assets bereit, nicht von Benutzern hochgeladene Dateien. + +Verwende dieses Dockerfile im Projektstammverzeichnis: + +```dockerfile +FROM python:3.13-slim +WORKDIR /app +COPY requirements.txt ./ +RUN pip install --no-cache-dir -r requirements.txt +COPY . . +RUN SECRET_KEY=build-only-placeholder \ + DATABASE_URL=postgresql://build:build@127.0.0.1:1/build \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + python manage.py collectstatic --noinput +EXPOSE 8000 +CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"] +``` + +Die Werte in der Zeile `RUN` gelten nur für `collectstatic`. Die Datenbank-URL ist ein Platzhalter, der auf einen ungenutzten lokalen Port zeigt; dort läuft keine Datenbank. Beim Laden der Einstellungen wird die URL geparst, aber das Sammeln von Assets benötigt keine Datenbankverbindung. Führe keine Datenbankabfragen aus Modulimporten oder `AppConfig.ready()` aus. Das Beispiel übergibt außerdem `collectstatic` bei deaktiviertem Containernetzwerk. + +Diese Zuweisungen werden nicht zu Umgebungsvariablen zur Laufzeit. Setze vor dem Start für den Service ein neues `SECRET_KEY` und die echte Datenbankreferenz. Übergib keine Produktionsgeheimnisse an den Docker-Build. + +Erstelle `.dockerignore` und schließe dieselben Pfade von [Source Uploads](/cli/up) aus: + +```text +.env* +.venv/ +venv/ +.git/ +__pycache__/ +*.pyc +*.sqlite3 +staticfiles/ +``` + +Bewahre Benutzer-Uploads in dauerhaftem Speicher auf, etwa [Managed Object Storage](/addons/storage), statt im statischen Verzeichnis des Containers. Prüfe [Speicherung und Wiederherstellung](/platform/storage-and-recovery). + +Behandle Datenbankmigrationen als separaten Release-Schritt. Sichere Daten bei Bedarf, mache Migrationen sicher erneut ausführbar und wende sie an, bevor Requests das neue Schema benötigen. Ein Befehl vor dem Bereitstellen ist kein Ersatz dafür, Nebenläufigkeit und Fehlerverhalten zu prüfen. + + + +## Bereitstellen und prüfen + +Nach dem [CLI-Setup](/framework-guides#prepare-the-project) verbindest du einen [GitHub-Service](/deploy/github), konfigurierst seine Secrets und Produktionseinstellungen und stellst ihn mit Container-Port `8000` bereit. Für ein neues uploadbasiertes Projekt: + +```bash +lizard init --name django-app +lizard add --service web +``` + +Erstelle [Managed Postgres](/addons/postgres) in diesem Projekt. Wenn du bereits eine Instanz hast, überspringe `add postgres` und verwende ihren Namen in der Referenz: + +```bash +lizard add postgres --name postgres +``` + +Setze die [Service Secrets](/cli/secrets) der App. Das `postgres` in `${{postgres.DATABASE_URL}}` bezeichnet den Datenbank-Service, nicht einen Django-Datenbankalias. Lizard löst die [Referenz](/variables/references) beim Bereitstellen auf und injiziert die resultierende URL in den Prozess `web`. Die einfachen Anführungszeichen verhindern, dass deine Shell die Referenz expandiert. Der oben stehende Block `settings.py` wandelt die URL dann in `DATABASES["default"]` um. + +```bash +DJANGO_SECRET_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(48))')" +lizard secrets set SECRET_KEY="$DJANGO_SECRET_KEY" \ + DATABASE_URL='${{postgres.DATABASE_URL}}' DEBUG=false \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + --service web +lizard up --service web --port 8000 +lizard ps --json +``` + +`localhost` ist eine vorläufige Host-Einstellung, die es dem Prozess erlaubt zu starten, während du seinen öffentlichen Hostnamen ermittelst; öffentliche Requests geben 400 zurück. Wenn du den Hostnamen bereits kennst, setze ihn vor dem ersten Upload. Andernfalls ersetze diese Platzhalter durch den Hostnamen und die HTTPS-Origin, die für deinen Service zurückgegeben wurden: + +```bash +lizard secrets set ALLOWED_HOSTS=YOUR_PUBLIC_HOST \ + CSRF_TRUSTED_ORIGINS=https://YOUR_PUBLIC_HOST --service web +``` + +Ein fehlendes Referenzziel oder ein fehlender Schlüssel kann zu einer leeren Zeichenfolge aufgelöst werden. Die Prüfung auf erforderliche Werte stoppt Django dann mit `Set the DATABASE_URL environment variable.`. Prüfe den Namen des Datenbank-Service und seinen Schlüssel `DATABASE_URL`; gib die Verbindungs-URL nicht in Logs aus. + +Die Variablenänderung startet den Prozess neu. Schließe lokale virtuelle Umgebungen, Secrets und lokale Datenbanken von Uploads aus. Sobald der Prozess läuft, wende Migrationen an: + +```bash +lizard ssh --service web -- python manage.py migrate --noinput +``` + +Führe den Befehl erneut aus, um zu prüfen, dass keine Migrationen mehr ausstehen. Betrachte eine erfolgreiche Port-Prüfung nicht als Nachweis dafür, dass Tabellen existieren. + +Prüfe die App-URL, eine datenbankgestützte Seite, eine Formularübermittlung und ein statisches Asset. Wenn die App Django admin verwendet, prüfe auch dessen CSS. Lies `lizard logs --service web --json` auf Import- oder Einstellungsfehler. Eine 400-Antwort bedeutet oft, dass `ALLOWED_HOSTS` falsch ist; fehlendes CSS bedeutet meist, dass statische Assets nicht gesammelt oder nicht bereitgestellt wurden. Prüfe den tatsächlichen Fehler, bevor du Einstellungen änderst. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Deployment-Prüfungen vom 9. September 2026 und ihre Grenzen. + + + + +## Dieses Beispiel reproduzieren + +Das [Django-Beispiel](https://github.com/lizard-build/docs/tree/main/_examples/django) enthält die Einstellungen, das Dockerfile, Requirements, ein datenbankgestütztes Formular und einen Test-Runner. Kopiere es in ein eigenständiges Verzeichnis und führe `python3 tests/verify.py` aus, während Docker läuft. Es baut das Image, startet lokales PostgreSQL, prüft Migrationen und HTTP-Verhalten und stoppt seine Test-Container. Es erstellt keine Lizard-Services. In der README findest du die Prüfungen und beibehaltenen Docker-Ressourcen. + +Die Prüfung vom 14. September 2026 deckt dieses überarbeitete Beispiel in lokalen Linux-Containern ab. Die oben verlinkten früheren Cloud-Ergebnisse beziehen sich auf die Anleitung vom 9. September; die überarbeiteten Einstellungen hatten noch kein neues Cloud-Deployment. diff --git a/_locales/de/framework-guides/docusaurus.mdx b/_locales/de/framework-guides/docusaurus.mdx new file mode 100644 index 0000000..d623f06 --- /dev/null +++ b/_locales/de/framework-guides/docusaurus.mdx @@ -0,0 +1,88 @@ +--- +description: "Stelle Docusaurus auf Lizard als statische Dokumentations-Website bereit. Erstelle das build-Verzeichnis, setze URL und baseUrl, verwende Port 80 und prüfe direkte Routen sowie echte 404-Fehler." +--- + + + +# Docusaurus auf Lizard bereitstellen + +Erstelle Docusaurus auf Lizard und liefere das erzeugte Verzeichnis `build/` über nginx auf Port `80` aus. Die Produktionsbereitstellung liefert statische Dateien aus; sie führt nicht den Entwicklungsserver `docusaurus start` aus. + +Beginne mit dem [vollständigen Quellcodebeispiel](https://github.com/lizard-build/docs/tree/main/_examples/docusaurus), das die Konfiguration und Dateien enthält, die in dieser Anleitung verwendet werden. + + + +## Website vorbereiten + +Führe den Befehl im Docusaurus-Verzeichnis aus, das `package.json`, die zugehörige Lockfile und `docusaurus.config.*` enthält. Belasse `@docusaurus/core` in den Abhängigkeiten sowie ein Build-Skript, das `docusaurus build` ausführt. + +| Einstellung | Wert | +|---|---| +| Build | `npm run build` | +| Output | `build/` | +| Runtime | nginx | +| Service-Port | `80` | + +Setze `url` in der Docusaurus-Konfiguration auf den vorgesehenen öffentlichen Ursprung der Website und `baseUrl` auf den Pfad, unter dem sie ausgeführt wird. Für eine Website an der Domain-Wurzel ist `baseUrl` gleich `/`. Sobald du den endgültigen Hostnamen kennst, erstelle die Website mit diesem Hostnamen neu, damit erzeugte kanonische URLs und Sitemap-Einträge ihn verwenden. + +Wähle eine konsistente Trailing-Slash-Richtlinie und prüfe die erzeugten Dateien. Behalte das Standard-Ausgabeverzeichnis bei, sofern du kein Dockerfile bereitstellst, das dein benutzerdefiniertes Verzeichnis kopiert. Der [Docusaurus-Bereitstellungsleitfaden](https://docusaurus.io/docs/deployment) erklärt diese Framework-Einstellungen. + + + +## Lokal erstellen und prüfen + +```bash +npm ci +npm run build +npm run serve +``` + +Der letzte Befehl setzt voraus, dass dein Projekt das Skript `serve` aus dem Scaffold enthält. Prüfe die Startseite, eine verschachtelte Dokumentationsseite, ein Bild und eine versionierte Seite, falls du Dokumentationsversionen verwendest. Behebe defekte Links, die beim Build gemeldet werden, vor der Bereitstellung. + + + +## Bereitstellen + +Nach dem [CLI-Setup](/framework-guides#prepare-the-project): + +```bash +lizard init --name docusaurus-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Wenn du den erzeugten Hostnamen verwendest, lies ihn nach der ersten Bereitstellung aus: + +```bash +lizard service show web --json +``` + +Setze `url` in `docusaurus.config.js` auf diesen Hostnamen: + +```js +url: 'https://YOUR_PUBLIC_HOST', +``` + +Lade die geänderte Konfiguration hoch, damit der Build die öffentliche URL verwendet: + +```bash +lizard up --service web --port 80 +``` + + +Committe Quellcode, Plugins, Konfiguration und die Lockfile. Schließe `node_modules/`-, `build/`-, `.docusaurus/`- und `.env`-Dateien von Uploads aus. Lasse Überschreibungen für den Service-Befehl ungesetzt, um den Docusaurus-Erkennungspfad zu verwenden. + + + +## Innere Routen und fehlende Seiten ausliefern + +Neue Docusaurus-Builds liefern erzeugte Routendateien aus und geben für unbekannte Pfade HTTP 404 zurück. Für diese Routing-Richtlinie ist kein benutzerdefiniertes Dockerfile erforderlich. Wenn dein Service noch ein Image verwendet, das vor dem Routing-Fix vom September 2026 erstellt wurde, erstelle es neu. Verwende [statische Routen und 404-Fehler](/framework-guides/static-routing) nur, wenn du benutzerdefiniertes nginx-Verhalten brauchst. + +Fordere nach der Bereitstellung direkt eine verschachtelte Docs-URL an, aktualisiere sie und prüfe den Status einer erfundenen URL. Prüfe außerdem die kanonische URL und die Sitemap auf dem endgültigen Hostnamen. Eine sichtbare Fehlerseite mit HTTP 200 ist weiterhin ein Soft-404. + +Wenn Assets fehlen, vergleiche ihre URLs mit `baseUrl`. Wenn eine innere Route die Startseite zurückgibt, prüfe das erzeugte Dateilayout und die nginx-Regeln. Wenn nach dem Bearbeiten eines Umgebungswerts oder einer Markdown-Datei weiterhin alter Inhalt angezeigt wird, verifiziere, dass tatsächlich ein neuer Build abgeschlossen wurde; statisches HTML ändert sich nur mit einem Build. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und deren Grenzen. + diff --git a/_locales/de/framework-guides/fastapi.mdx b/_locales/de/framework-guides/fastapi.mdx new file mode 100644 index 0000000..af89b4a --- /dev/null +++ b/_locales/de/framework-guides/fastapi.mdx @@ -0,0 +1,98 @@ +--- +description: "Stelle FastAPI auf Lizard mit Uvicorn, requirements.txt, einem Procfile und Port 8000 bereit. Prüfe einen Health-Endpunkt und diagnostiziere Import-, Host- und Abhängigkeitsfehler." +--- + + + +# FastAPI auf Lizard bereitstellen + +Führe FastAPI auf Lizard aus, wobei Uvicorn auf `0.0.0.0:8000` lauscht. Nimm sowohl FastAPI als auch Uvicorn in die Abhängigkeiten der App auf. Das Importieren einer Datei, die `app = FastAPI()` deklariert, startet nicht von selbst einen HTTP-Server. + + + +## Beispielprojekt + +Das [FastAPI-Beispiel](https://github.com/lizard-build/fastapi-example) enthält eine App, ein Procfile, festgelegte Abhängigkeiten, eine MIT-Lizenz und HTTP-Tests. Seine CI führt den Uvicorn-Produktions-Einstiegspunkt unter Linux aus. Wir haben außerdem den Commit `df522c1` von GitHub bereitgestellt und am 2026-09-09 Health, OpenAPI, interaktive Docs, JSON-Echo, ungültige Eingaben und eine fehlende Route über öffentliches HTTPS geprüft. + + + +## Eine App vorbereiten + +Dieses Beispiel verwendet `requirements.txt` und eine `main.py` im App-Stammverzeichnis: + +```python +from fastapi import FastAPI + +app = FastAPI() + +@app.get("/health") +def health(): + return {"status": "ok"} +``` + +Füge `fastapi` und `uvicorn` zu deinem Abhängigkeits-Workflow hinzu und speichere die aufgelösten, getesteten Versionen in `requirements.txt`. Wähle deine Python-Nebenversion in `.python-version`, zum Beispiel `3.13`, wenn deine Abhängigkeiten sie unterstützen. + +Erstelle eine `Procfile` mit einem expliziten Importziel: + +```text +web: uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +`main:app` bedeutet das Objekt `app` in `main.py`. Für `src/api.py` verwende den Importpfad, der von deinem App-Stamm aus funktioniert, etwa `src.api:app`. Das explizite Procfile vermeidet, sich bei benutzerdefinierten Layouts auf die Erkennung von Quellcode-Mustern zu verlassen. + +| Einstellung | Wert | +|---|---| +| Installation | `pip install -r requirements.txt` | +| Start | Procfile-Befehl `web:` | +| Service-Port | `8000` | +| Build-Ausgabe | Python-Quellcode und installierte Abhängigkeiten | + + + +## Lokal testen + +Verwende eine lokale virtuelle Umgebung: + +```bash +python -m venv .venv +source .venv/bin/activate +pip install -r requirements.txt +uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +In einem anderen Terminal: + +```bash +curl --fail http://localhost:8000/health +``` + +Erwarte eine erfolgreiche Antwort mit `{"status":"ok"}`. Behalte den Reload-Modus für die Entwicklung bei. Der [FastAPI-Serverleitfaden](https://fastapi.tiangolo.com/deployment/manually/) erklärt den ASGI-Server und das Importziel. + + + +## Bereitstellen + +Nach dem [CLI-Setup](/framework-guides#prepare-the-project) lade aus dem App-Stammverzeichnis hoch: + +```bash +lizard init --name fastapi-app +lizard add --service api +lizard up --service api --port 8000 +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +Schließe Dateien vom Typ `.venv/`, `__pycache__/` und `.env` aus. Lasse Service-Build-/Start-Overrides leer, damit lizardpack das Procfile liest. Der requirements-basierte Pfad hier benötigt keinen separaten Compile-Befehl. + +Rufe `/health` unter der zurückgegebenen HTTPS-URL auf und teste dann eine echte API-Aktion. Ein TCP-Health-Check stellt nur fest, dass der Prozess seinen Port öffnet; dein Health-Endpunkt kann Prüfungen ergänzen, die für die App relevant sind. + + + +## Daten und häufige Fehler + +Setze Zugangsdaten über [Variablen und Secrets](/variables). Füge [Managed Postgres](/addons/postgres) hinzu, wenn die App eine Datenbank benötigt, und verwende eine servicebezogene Verbindungsreferenz. Container-lokale Dateien sind kein dauerhaftes Anwendungsspeicher; siehe [Storage und Wiederherstellung](/platform/storage-and-recovery). + +Prüfe bei `No module named uvicorn` die installierten requirements. Führe bei einem ASGI-Importfehler den exakten Procfile-Befehl lokal vom selben Stammverzeichnis aus. Wenn ein Service nie healthy wird, prüfe Port `8000` und den Bind-Host. Wenn der Prozess ohne Server-Logs beendet wird, stelle sicher, dass er Uvicorn ausführt und nicht nur `python main.py`. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Deployment-Prüfungen vom 9. September 2026 und ihre Grenzen. diff --git a/_locales/de/framework-guides/hugo.mdx b/_locales/de/framework-guides/hugo.mdx new file mode 100644 index 0000000..0f1a543 --- /dev/null +++ b/_locales/de/framework-guides/hugo.mdx @@ -0,0 +1,89 @@ +--- +description: "Stelle Hugo auf Lizard bereit, indem du public mit hugo --minify baust und es auf Port 80 auslieferst. Prüfe Erkennung, Themes, baseURL, generierte Routen und den Status fehlender Seiten." +--- + + + +# Hugo auf Lizard bereitstellen + +Lizard kann eine Hugo-Quellseite mit `hugo --minify` bauen und `public/` über nginx auf Port `80` ausliefern. Starte im Hugo-Quellverzeichnis mit einer Hugo-Konfiguration und `content/`, statt nur das generierte HTML hochzuladen. + +Beginne mit dem [vollständigen Quellbeispiel](https://github.com/lizard-build/docs/tree/main/_examples/hugo), das die Konfiguration und Dateien enthält, die in dieser Anleitung verwendet werden. + + + +## Quelle vorbereiten + +Füge deine Hugo-Konfiguration, Inhalte, Layouts, Assets und alle Theme-Dateien ein, die der Build benötigt. Die Hugo-Erkennung sucht nach einer Konfiguration wie `hugo.toml`, `hugo.yaml` oder `config/_default/` sowie nach einem Verzeichnis `content/`. + +| Einstellung | Wert | +|---|---| +| Build | `hugo --minify` | +| Output | `public/` | +| Produktionsserver | nginx | +| Service-Port | `80` | + +Setze `baseURL` auf die vorgesehene öffentliche Website-URL einschließlich des abschließenden Schrägstrichs. Baue nach der Zuweisung eines anderen Hostnamens neu, damit Links und generierte Sitemap-Einträge ihn verwenden. Siehe [Hugos Anleitung zu Build und Output](https://gohugo.io/getting-started/usage/). + + + +## Build-Abhängigkeiten prüfen + +Das Standard-Build-Image für Hugo ist `hugomods/hugo:base`; es legt für dein Projekt keine Hugo-Version fest. Wenn ein Theme eine bestimmte Hugo-Version, die Extended Edition oder Node-Tooling benötigt, verwende ein vollständiges Dockerfile mit diesen Abhängigkeiten und der Version, die du getestet hast. + +Eine Hugo-Konfiguration und `content/` wählen den Hugo-Builder vor der Erkennung von Go oder Node aus. Projekte mit Hugo Modules und `go.mod` verwenden ein Build-Image mit Go-Unterstützung. Eine `package.json` beendet den Build mit der Aufforderung, ein Dockerfile bereitzustellen: Installiere die Node-Abhängigkeiten, baue die Assets und führe dann `hugo --minify` aus. Siehe [Reihenfolge der Build-Entscheidung](/concepts/build-pipeline#build-decision-order). + + + +## Lokal bauen und bereitstellen + +```bash +hugo --minify +hugo server +``` + +Prüfe `public/` nach dem ersten Befehl. Nutze den lokalen Server, um Inhalte und Theme-Rendering zu prüfen; `hugo server` ist nicht der Produktions-Startbefehl. + +Stelle nach dem [CLI-Setup](/framework-guides#prepare-the-project) das Quellverzeichnis bereit: + +```bash +lizard init --name hugo-site +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Wenn du den generierten Hostnamen verwendest, lies ihn nach dem ersten Bereitstellen aus: + +```bash +lizard service show web --json +``` + +Setze `baseURL` in `hugo.toml` auf diesen Hostnamen: + +```toml +baseURL = "https://YOUR_PUBLIC_HOST/" +``` + +Lade die geänderte Konfiguration hoch, damit der Build die öffentliche URL verwendet: + +```bash +lizard up --service web --port 80 +``` + + +Schließe lokal generierten Output und Secrets aus. Stelle bei einem Upload sicher, dass die Theme-Quelldateien tatsächlich in dem Verzeichnis vorhanden sind, das du sendest; ein entfernter Submodule-Verweis allein ist nicht der Theme-Inhalt. + + + +## Die bereitgestellte Website prüfen + +Öffne die Live-Startseite, einen internen Artikel und ein Bild. Prüfe die generierten kanonischen URLs und `sitemap.xml`. Teste den HTTP-Status eines erfundenen Pfads. Neue Hugo-Builds liefern das generierte HTML aus und geben für fehlende Seiten HTTP 404 zurück. Für das einfache Quelllayout in dieser Anleitung ist kein eigenes Dockerfile erforderlich. Baue ältere Images neu, um die aktuellen Routing-Regeln zu übernehmen. + +Verwende [statische Routen und 404er](/framework-guides/static-routing), wenn du eine benutzerdefinierte nginx-Richtlinie benötigst. Eine benutzerdefinierte Hugo-Build-Stage muss die vom Theme benötigte Hugo-Version und Tools enthalten, `hugo --minify` ausführen und `public/` in das ausliefernde Image kopieren. + +Wenn Theme-Assets fehlen, prüfe die Build-Logs, die Theme-Quelle und `baseURL`. Wenn der falsche Builder startet, prüfe, ob die Hugo-Konfiguration und `content/` im Upload-Root liegen, und überprüfe vorhandene Service-Overrides. Hugo erzeugt statische Dateien, daher erfordern Inhaltsänderungen einen neuen Build. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellen-Prüfungen vom 9. September 2026 und ihre Grenzen. + diff --git a/_locales/de/framework-guides/index.mdx b/_locales/de/framework-guides/index.mdx new file mode 100644 index 0000000..6726ce4 --- /dev/null +++ b/_locales/de/framework-guides/index.mdx @@ -0,0 +1,69 @@ +--- +description: "Stelle Next.js, React, Vue, Astro, Nuxt, SvelteKit, FastAPI, Django, Docusaurus, VitePress und Hugo auf Lizard bereit. Finde Build-Befehle, Adapter, Ports und Prüfungen." +--- + + + +# Framework-Anleitungen + +Stelle eine Framework-App aus dem Quellcode auf Lizard bereit. Wähle unten dein Framework und den Rendering-Modus, bereite den Produktions-Build vor und stelle dann mit Lizard CLI bereit oder verbinde ein GitHub-Repository. Server-Apps führen einen Prozess aus; statische Websites liefern die generierten Dateien über nginx aus. + + + +## Wähle dein Framework + +Diese Einstellungen beschreiben die Standard-Projektlayouts in den verlinkten Anleitungen. Die Befehle gehen bei JavaScript-Projekten von npm aus. Benutzerdefinierte Ausgabepfade, Adapter und Build-Überschreibungen können das Ergebnis ändern. + +| Framework | Build | Laufzeit oder Ausgabe | Service-Port | +|---|---|---|---| +| [Next.js](/framework-guides/nextjs) | `npm run build` | `next start` über das Start-Skript | `3000` | +| [Next.js statischer Export](/framework-guides/nextjs/static-export) | `npm run build` | `out/` über ein Dockerfile | `80` | +| [React with Vite](/framework-guides/react) | `npm run build` | `dist/` | `80` | +| [Vue with Vite](/framework-guides/vue) | `npm run build` | `dist/` | `80` | +| [Astro](/framework-guides/astro) | `npm run build` | `dist/` oder der eigenständige Node-Adapter | `80` statisch; `3000` Server | +| [Nuxt](/framework-guides/nuxt) | `npm run build` | `node .output/server/index.mjs` | `3000` | +| [SvelteKit](/framework-guides/sveltekit) | `npm run build` | `node build` mit adapter-node | `3000` | +| [FastAPI](/framework-guides/fastapi) | Python-Abhängigkeiten installieren | `uvicorn main:app --host 0.0.0.0 --port 8000` | `8000` | +| [Django](/framework-guides/django) | Python-Abhängigkeiten installieren | Gunicorn mit deinem WSGI-Modul | `8000` | +| [Docusaurus](/framework-guides/docusaurus) | `npm run build` | `build/` | `80` | +| [VitePress](/framework-guides/vitepress) | `npm run docs:build` | `docs/.vitepress/dist/` in dieser Anleitung | `80` | +| [Hugo](/framework-guides/hugo) | `hugo --minify` | `public/` | `80` | + + + +## Projekt vorbereiten + +Führe die Befehle im Anwendungsverzeichnis aus. Übertrage Quellcodedateien, Konfiguration und die Package-Lockdatei ins Commit. Schließe `.env`, lokale Abhängigkeiten und lokale Build-Ausgabe von Uploads aus. Node-Projekte können die Node-Hauptversion in `.nvmrc` auswählen; der aktuelle Standard ist `22`. Damit wird eine Hauptversion ausgewählt, keine genaue Patch-Version. + +Installiere Lizard CLI und melde dich einmal an: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +Jede Anleitung verwendet ein neues Projekt und einen Service mit dem Namen `web` oder `api`. Erstelle diesen Service mit `lizard add --service web` (oder `api`) vor dem ersten Aufruf von `lizard up --service`. `up --service` wählt einen vorhandenen Service aus; ein fehlender benannter Service wird dadurch nicht erstellt. Prüfe bei einem bestehenden Projekt vor der Bereitstellung `lizard status --json` und `lizard ps --json`. Der Port muss zum Prozess im Container passen, der auf `0.0.0.0` lauschen muss. + +Lizard CLI 0.3.95 schließt macOS-Archivmetadaten bei Uploads aus. Eine Einstellung für `COPYFILE_DISABLE` ist nicht erforderlich. Aktualisiere ältere CLI-Versionen, bevor du diesen Anleitungen folgst. + + + +## GitHub oder lokalen Quellcode wählen + +Die Befehle in dieser Anleitung verwenden `lizard up`, um den aktuellen Ordner hochzuladen. Dieser Befehl stellt einen bestehenden Service auf Quellcode-Upload um. Wenn du git push to deploy beibehalten möchtest, [verbinde GitHub](/deploy/github) stattdessen und verwende die Build-Einstellungen der Anleitung im Repository. Konfiguriere den Service-Port anhand der Tabelle. + + + +## Build-Einstellungen konsistent halten + +Diese Anleitungen verwenden lizardpack-Erkennung, sofern nicht ein Dockerfile verlangt wird. Bestehende Überschreibungen in `buildCommand` oder `startCommand` haben Vorrang vor der Erkennung und dem Dockerfile im Repository. Prüfe die [Reihenfolge der Build-Entscheidung](/concepts/build-pipeline#build-decision-order), bevor du die Build-Methode wechselst. Setze Skripte in `package.json`, wenn eine Anleitung dich dazu auffordert; das Hinzufügen einer CLI-Überschreibung ist ein anderer Build-Pfad. + + + +## Ein Release prüfen + +Lies die Build-Logs, Laufzeit-Logs und die aktive URL. Teste eine interne Route, eine fehlende Route und jede API oder Formularaktion. Ein Prozess, der seinen Port öffnet, kann trotzdem eine fehlerhafte Seite ausliefern. Verwende für generierte Websites [statische Routen und 404-Seiten](/framework-guides/static-routing), damit nicht für jede unbekannte URL die Startseite mit HTTP 200 zurückgegeben wird. + +Laufzeitunterstützung bedeutet nicht gemeinsam genutzte Caches, persistente lokale Dateien oder jede Framework-Version. Sieh unter [Limits](/platform/limits), [Storage und Wiederherstellung](/platform/storage-and-recovery) und [bekannte Probleme](/platform/known-issues) nach, wenn deine App auf diese Funktionen angewiesen ist. + +Sieh unter [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) nach für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Limits. diff --git a/_locales/de/framework-guides/nextjs/_meta.ts b/_locales/de/framework-guides/nextjs/_meta.ts new file mode 100644 index 0000000..25beece --- /dev/null +++ b/_locales/de/framework-guides/nextjs/_meta.ts @@ -0,0 +1,4 @@ +export default { + index: "Next.js", + 'static-export': { title: "Statischer Export", display: "ausgeblendet" }, +}; diff --git a/_locales/de/framework-guides/nextjs/index.mdx b/_locales/de/framework-guides/nextjs/index.mdx new file mode 100644 index 0000000..7c78e3d --- /dev/null +++ b/_locales/de/framework-guides/nextjs/index.mdx @@ -0,0 +1,95 @@ +--- +description: "Stelle Next.js auf Lizard als Node.js-Server bereit. Konfiguriere next build, next start, Port 3000, Umgebungsvariablen und Prüfungen für Seiten, APIs und Server Actions." +--- + + + +# Next.js auf Lizard bereitstellen + +Führe Next.js auf Lizard als Node.js-Server mit `next build` und `next start` aus. Dieser Weg hält einen Server für Rendering zur Anfragezeit, Route Handlers und Server Actions verfügbar. Wenn jede Route vorab gebaut werden kann, folge stattdessen [Next.js statischer Export](/framework-guides/nextjs/static-export). + + + +## Build-Einstellungen + +| Einstellung | Wert | +|---|---| +| Projektstamm | Verzeichnis mit `package.json` und der Next.js-Konfiguration | +| Build-Skript | `next build` | +| Start-Skript | `next start --hostname 0.0.0.0 --port 3000` | +| Build-Ausgabe | `.next/` | +| Service-Port | `3000` | +| Laufzeit | Node.js | + + + +## App vorbereiten + +Behalte `next`, `react` und `react-dom` in deinen Abhängigkeiten und committe deine Lockfile. Füge diese Skripte in `package.json` zusammen: + +```json +{ + "scripts": { + "dev": "next dev", + "build": "next build", + "start": "next start --hostname 0.0.0.0 --port 3000" + } +} +``` + +Verwende für diesen Leitfaden die Standardausgabe von Next.js. `output: 'export'` benötigt einen statischen Server, und `output: 'standalone'` benötigt einen eigenen Start mit `server.js` und ein eigenes Asset-Layout. Keines von beiden verwendet dieses `next start`-Rezept unverändert. + +Wähle in `.nvmrc` eine unterstützte Node-Hauptversion aus, zum Beispiel `22`. Schließe `.next/`, `node_modules/` und `.env*` aus dem hochgeladenen Quellcode aus; behalte bei Bedarf eine Beispiel-Umgebungsdatei ohne Geheimnisse. + + + +## Den Produktions-Build lokal testen + +```bash +npm ci +npm run build +npm run start +``` + +Öffne in einem anderen Terminal `http://localhost:3000` und teste eine innere Route. Wenn die App eine API oder Server Aktion hat, führe auch dafür einen Test aus. Nur weil die Prüfung des Entwicklungsservers erfolgreich ist, ist nicht bewiesen, dass der Produktions-Build funktioniert. + + + +## Bereitstellen + +Führe nach dem [Installieren von Lizard CLI und der Anmeldung](/framework-guides#prepare-the-project) aus dem App-Verzeichnis Folgendes aus: + +```bash +lizard init --name nextjs-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Lizard erkennt die Abhängigkeit `next` und führt die Build- und Start-Skripte aus. Diese Befehle setzen voraus, dass der Service noch keine bestehenden Build- oder Start-Overrides hat. Verwende die URL in der Bereitstellen-Ausgabe, um die lokalen Prüfungen zu wiederholen. + + + +## Umgebungsvariablen und Daten + +Werte aus `NEXT_PUBLIC_*` werden während des Builds Teil des Browser-Bundles. Bewahre Zugangsdaten in rein serverseitigen Variablen auf und konfiguriere sie für den Service über [Variablen und Secrets](/variables). Code, der während des Builds Daten abruft, benötigt auch zu diesem Zeitpunkt Zugriff auf diese Daten. Ein Neustart zur Laufzeit ändert kein bereits generiertes HTML oder JavaScript. + +Lokale Cache-Dateien und hochgeladene Dateien bilden keinen gemeinsamen Speicher über Replikate hinweg. Prüfe die Anforderungen von Next.js für Cache und Server Actions, bevor du auf mehr als ein Replikat skalierst. Lege dauerhafte App-Daten in einer Datenbank oder einem Objektspeicher ab und lies [Storage und Recovery](/platform/storage-and-recovery). + + + +## Fehlerbehebung + +| Symptom | Prüfen | +|---|---| +| `Missing script: start` | Füge das Produktions-Start-Skript oben hinzu; `next dev` ist für die lokale Entwicklung. | +| App wird nie healthy | Stimme `--port 3000` auf den Startbefehl ab und binde an `0.0.0.0`. | +| Die öffentliche API-URL hat noch ihren alten Wert | Erstelle mit dem neuen Wert für `NEXT_PUBLIC_*` einen neuen Build. | +| Der Build kann keine Datenbank erreichen | Prüfe, ob eine Route Daten zur Build-Zeit abruft und ob diese Abhängigkeit dann erreichbar ist. | +| Static export schlägt unter `next start` fehl | Folge dem separaten Leitfaden für static export. | + +Der [Next.js Self-Hosting-Anleitung](https://nextjs.org/docs/app/guides/self-hosting) behandelt das Verhalten von Framework-Cache, Bildern und mehreren Instanzen. Bei Bereitstellungsfehlern siehe [Service wird nie gesund](/deploy/troubleshooting/service-never-healthy). + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen. diff --git a/_locales/de/framework-guides/nextjs/static-export.mdx b/_locales/de/framework-guides/nextjs/static-export.mdx new file mode 100644 index 0000000..ef44294 --- /dev/null +++ b/_locales/de/framework-guides/nextjs/static-export.mdx @@ -0,0 +1,106 @@ +--- +description: "Stellen Sie einen statischen Next.js-Export auf Lizard mit output export, einem nginx-Dockerfile, Port 80 und echten 404-Antworten bereit. Erfahren Sie, welche Funktionen weiterhin einen Node.js-Server benötigen." +--- + + + +# Einen statischen Next.js-Export bereitstellen + +Ein statischer Next.js-Export erzeugt HTML, JavaScript und Assets in `out/`. Stellen Sie dieses Verzeichnis auf Lizard mit einem nginx-Dockerfile bereit. Verwenden Sie diesen Weg für Seiten, die vorab gebaut werden können; verwenden Sie den Leitfaden für den [Node.js-Server](/framework-guides/nextjs) für Serverfunktionen zur Anfragezeit. + + + +## Den Export konfigurieren + +Fügen Sie diese Optionen in `next.config.mjs` zusammen: + +```js +/** @type {import('next').NextConfig} */ +const nextConfig = { + output: 'export', + trailingSlash: true, + images: { unoptimized: true }, +}; + +export default nextConfig; +``` + +Behalten Sie `"build": "next build"` in `package.json` bei. Dieses Beispiel verwendet einfache exportierte Bilder; ein externer Image-Loader ist eine weitere Option. Erzeugen Sie während des Builds alle erforderlichen Parameter für dynamische Routen. Cookies zur Anfragezeit, Server Actions und andere Funktionen, die einen laufenden Next.js-Server benötigen, können in diesem statischen Container nicht ausgeführt werden. Prüfen Sie die [Next.js-Referenz für statische Exporte](https://nextjs.org/docs/app/guides/static-exports) gegen die Funktionen, die Ihre App verwendet. + + + +## Ein vollständiges Dockerfile hinzufügen + +Die automatische Erkennung für Next.js erwartet einen Node-Server. Sie wechselt nicht zu nginx, nur weil die Konfiguration `out/` exportiert. Fügen Sie dieses Dockerfile im App-Stammverzeichnis hinzu; es setzt npm und ein eingechecktes `package-lock.json` voraus: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +RUN npm run build + +FROM nginx:alpine +COPY --from=build /app/out /usr/share/nginx/html +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +Erstellen Sie daneben `nginx.conf`: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + location / { + try_files $uri $uri/ =404; + } + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +Der Export mit Trailing Slash erstellt Routenverzeichnisse mit `index.html`. Die nginx-Regel bedient diese Verzeichnisse und gibt für fehlende Pfade HTTP 404 zurück. Fügen Sie `node_modules`, `.next`, `out`, `.git` und `.env*` zu `.dockerignore` hinzu und schließen Sie lokale Build-Dateien von Uploads aus. + + + +## Bauen und bereitstellen + +```bash +npm ci +npm run build +``` + +Prüfen Sie, dass `out/index.html` und eine erwartete innere Route vorhanden sind. Wenn Docker verfügbar ist, testen Sie den tatsächlichen Server lokal: + +```bash +docker build -t nextjs-static . +docker run --rm -p 8080:80 nextjs-static +``` + +Nach der [CLI-Einrichtung](/framework-guides#prepare-the-project) stellen Sie in einem neuen Service bereit: + +```bash +lizard init --name nextjs-static +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Das vollständige Dockerfile enthält einen npm-Build-Schritt, den lizardpack erkennen kann. Prüfen Sie bei einem bestehenden Service vor der Auswahl eines Dockerfiles widersprüchliche Build-/Start-Überschreibungen und entfernen Sie sie; siehe [Reihenfolge der Build-Entscheidung](/concepts/build-pipeline#build-decision-order). + + + +## Routen und Aktualisierungen prüfen + +Rufen Sie die Live-Startseite, eine exportierte innere Route, ein JavaScript-Asset und einen erfundenen Pfad auf. Der erfundene Pfad muss HTTP 404 zurückgeben, nicht die Startseite mit HTTP 200. Verwenden Sie die Prüfungen unter [statische Routen und 404er](/framework-guides/static-routing#verify-http-responses). + +Alle Änderungen an exportierten Inhalten erfordern einen neuen Build. Laufzeit-Umgebungsvariablen können Werte, die bereits in `out/` geschrieben wurden, nicht ändern. Deklarieren Sie für öffentliche Build-Variablen in einem benutzerdefinierten Dockerfile das erforderliche `ARG` vor `RUN npm run build`; legen Sie niemals private Zugangsdaten im exportierten Bundle ab. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen. diff --git a/_locales/de/framework-guides/nuxt.mdx b/_locales/de/framework-guides/nuxt.mdx new file mode 100644 index 0000000..5f2d23c --- /dev/null +++ b/_locales/de/framework-guides/nuxt.mdx @@ -0,0 +1,109 @@ +--- +description: "Stelle Nuxt auf Lizard mit Nitros node-server-Preset bereit. Füge ein Produktions-Startskript hinzu, starte den generierten Server auf Port 3000 und prüfe Routen sowie Runtime-Konfiguration." +--- + + + +# Nuxt auf Lizard bereitstellen + +Führe Nuxt auf Lizard mit Nitros `node-server`-Preset aus. Der Build erzeugt `.output/server/index.mjs`, und ein Node.js-Prozess stellt Seiten und Server-Routen auf Port `3000` bereit. Für eine generierte Website auf Port `80` verwende das statische Rezept unten. + + + +## Produktions-Build konfigurieren + +Verwende die aktuelle Lizard CLI aus [Projekt vorbereiten](/framework-guides#prepare-the-project). Version 0.3.95 schließt macOS-Archivmetadaten beim Hochladen aus. Wenn eine ältere CLI einen `._*.ts`-Routenfehler meldet, aktualisiere die CLI und lade erneut hoch. + +Setze das Preset in `nuxt.config.ts`: + +```ts +export default defineNuxtConfig({ + nitro: { preset: 'node-server' }, +}); +``` + +Füge diese Skripte in `package.json` zusammen und behalte alle weiteren Skripte bei, die deine App benötigt: + +```json +{ + "scripts": { + "dev": "nuxt dev", + "build": "nuxt build", + "start": "HOST=0.0.0.0 PORT=3000 node .output/server/index.mjs" + } +} +``` + +Das Startskript verwendet die Linux-Shell im Deployment-Container. lizardpack erkennt die Abhängigkeit `nuxt` und führt die Build- und Startskripte aus. Ein frisches Nuxt-Projekt enthält `start` möglicherweise nicht; füge es hinzu, statt davon auszugehen, dass `nuxt dev` den Produktions-Build bereitstellt. + +| Einstellung | Wert | +|---|---| +| Build | `npm run build` | +| Server entry | `.output/server/index.mjs` | +| Start | `npm run start` | +| Service-Port | `3000` | + + + +## Gebaute App testen + +```bash +npm ci +npm run build +npm run start +``` + +Öffne `http://localhost:3000`, rufe direkt eine Unterseite auf und rufe eine deiner `server/api`-Routen auf, falls vorhanden. Prüfe, dass der Build das Node-Server-Preset meldet. Ein anbieterspezifisches Nitro-Preset kann einen anderen Einstiegspunkt erzeugen. + + + +## Bereitstellen + +Führe nach der [CLI-Einrichtung](/framework-guides#prepare-the-project) im Verzeichnis der Nuxt-App aus: + +```bash +lizard init --name nuxt-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Halte `.nuxt/`-, `.output/`-, `node_modules/`- und `.env`-Dateien aus dem Upload heraus. Schließe Quellcode, Konfiguration und die Lockfile ein. Vorhandene Build-/Start-Überschreibungen des Services umgehen die hier verwendete Erkennung; siehe [Reihenfolge der Build-Entscheidung](/concepts/build-pipeline#build-decision-order). + + + +## Runtime-Konfiguration + +Deklariere Runtime-Einstellungen in `runtimeConfig` und konfiguriere die passenden `NUXT_*`-Werte für den Service. Bewahre Geheimnisse außerhalb von `runtimeConfig.public` auf; der öffentliche Teil gelangt in den Browser. Werte, die zum Prerendern von Seiten verwendet werden, beeinflussen weiterhin den generierten Build, also prüfe nach einer Änderung sowohl Routen zur Anfragezeit als auch vorgenerierte Routen. + +Verwende [Variablen und Secrets](/variables), um den Service zu konfigurieren, und [Speicherung und Wiederherstellung](/platform/storage-and-recovery) für dauerhafte Daten. Behandle einen lokalen Cache oder eine Session-Datei nicht als gemeinsam genutzten Speicher über Replikate hinweg. + + + +## Fehlerbehebung + +Wenn der Prozess ein fehlendes `.output/server/index.mjs` meldet, prüfe das Preset und die Build-Ausgabe. Wenn ein fehlendes Startskript gemeldet wird, füge das oben genannte hinzu. Wenn die Website nie healthy wird, prüfe Host und Port. + +Für eine rein generierte Nuxt-Website stelle `.output/public/` mit einem statischen Dockerfile und korrekter Routenbehandlung bereit. Starte diese Ausgabe nicht mit dem obigen Node-Befehl. Der [Nuxt-Deployment-Leitfaden](https://nuxt.com/docs/4.x/getting-started/deployment) erklärt die Node- und generierten Ausgaben; [statische Routen und 404-Seiten](/framework-guides/static-routing) behandelt die Einrichtung des statischen Lizard-Servers. + + + +## Statische Website generieren + +Ersetze für generiertes HTML das Node-Preset durch explizite Prerender-Einstellungen und ändere das Build-Skript zu `nuxt generate`: + +```ts +export default defineNuxtConfig({ + nitro: { + prerender: { crawlLinks: true, routes: ['/'] }, + }, +}); +``` + +Füge nicht verlinkte oder dynamische Routen zu `routes` hinzu, wenn der Crawler sie nicht erkennen kann. Führe `npm run build` aus und prüfe, dass `.output/public/index.html` und deine Dateien für Unterrouten vorhanden sind. Im Test mit Nuxt 4.5.2 führte das Beibehalten von `preset: 'node-server'` bei einem Wechsel nur zu `nuxt generate` zu den Fallback-Seiten ohne die Routen der Website. Ein erfolgreicher Build allein zeigte nicht, dass der Export die Website enthielt. + +Verwende das Dockerfile und die nginx-Konfiguration aus [statische Routen und 404-Seiten](/framework-guides/static-routing), mit dem Build-Skript `build`, dem Ausgabeverzeichnis `.output/public` und dem Service-Port `80`. Der statische Container führt keine Nuxt-Server-Routen aus und liest keine Runtime-Konfiguration für bereits generierte Seiten. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Deployment-Prüfungen vom 9. September 2026 und ihre Grenzen. diff --git a/_locales/de/framework-guides/react.mdx b/_locales/de/framework-guides/react.mdx new file mode 100644 index 0000000..e6f6a1f --- /dev/null +++ b/_locales/de/framework-guides/react.mdx @@ -0,0 +1,83 @@ +--- +description: "Stelle eine mit Vite erstellte React-App auf Lizard bereit. Erstelle dist, liefere sie über Port 80 aus, konfiguriere Client-Routen und öffentliche API-Variablen und prüfe die bereitgestellte App." +--- + + + +# React mit Vite auf Lizard bereitstellen + +Lizard erstellt eine React-App, die Vite verwendet, und liefert ihr Verzeichnis `dist/` über nginx auf Port `80` aus. Diese Anleitung behandelt eine im Browser gerenderte App. Für React-Seiten, die einen Server benötigen, folge der [Next.js-Anleitung](/framework-guides/nextjs) oder stelle einen Produktionsserver für dein gewähltes React-Framework bereit. + + + +## Build vorbereiten + +Verwende ein bestehendes React- und Vite-Projekt mit einer eingecheckten Lockfile. Seine `package.json` benötigt ein Produktions-Build-Skript: + +```json +{ + "scripts": { + "dev": "vite", + "build": "vite build", + "preview": "vite preview" + } +} +``` + +Wenn dein Scaffold vor `vite build` TypeScript-Prüfungen ausführt, behalte diese Prüfungen bei. Behalte Vites Standard-Ausgabeverzeichnis `dist` bei. Ein benutzerdefiniertes `build.outDir` benötigt ein passendes Dockerfile, weil der Standard-Erkennungspfad `dist` kopiert. + +| Einstellung | Wert | +|---|---| +| Erkennung | `vite` in dependencies oder dev dependencies | +| Build | `npm run build` | +| Ausgabe | `dist/` | +| Produktionsserver | nginx; kein Node-Startskript nötig | +| Service-Port | `80` | + + + +## Lokal testen + +```bash +npm ci +npm run build +npm run preview +``` + +Öffne die lokale Preview-URL und teste eine Seite, die deine API aufruft. Der Preview-Befehl prüft den Build lokal; setze `vite preview` nicht als Produktions-Startbefehl. Siehe [Vite deployment](https://vite.dev/guide/static-deploy.html). + + + +## Den Quellcode bereitstellen + +Führe nach dem [CLI-Setup](/framework-guides#prepare-the-project) im Verzeichnis mit `package.json` Folgendes aus: + +```bash +lizard init --name react-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Lade den Quellcode und die Lockfile hoch, aber schließe `node_modules/`, `dist/` und Secrets aus. Lasse Überschreibungen für Service-Build/Start deaktiviert, um den statischen Erkennungspfad zu verwenden. Der nginx-Container lauscht auf Port 80, obwohl die Entwicklungs- und Preview-Server andere Ports verwenden. + + + +## Eine API verbinden + +Verwende eine öffentliche Variable wie `VITE_API_URL` für die per HTTPS im Browser erreichbare Adresse der API. Lies sie als `import.meta.env.VITE_API_URL` aus. Konfiguriere diesen Wert über [Variablen und Secrets](/variables) und erstelle die App neu, wenn er sich ändert. Stelle niemals eine Datenbank-URL, API-Zugangsdaten oder eine nur intern erreichbare Service-Adresse über eine Variable vom Typ `VITE_*` bereit. + +Für eine API auf einer anderen Origin konfiguriere die erlaubten Origins so, dass sie die Frontend-URL einschließen. Ein privater Service-Hostname, der zwischen Backend-Services funktioniert, wird im Browser eines Besuchers nicht aufgelöst. + + + +## Routing prüfen + +Öffne die Live-App, folge einer Client-Route und lade diese URL dann direkt neu. Der Standard-Static-Server fällt auf `index.html` zurück, damit der Client-Router eine interne Route rendern kann. Füge auch in der React-App eine Route für unbekannte Pfade hinzu. Dieser Fallback liefert weiterhin HTTP 200 zurück; verwende [statische Routen und 404s](/framework-guides/static-routing), um eine Serverrichtlinie für Seiten zu wählen, die echte HTTP-404-Antworten benötigen. + +Wenn ein Asset HTML zurückgibt oder die Seite leer bleibt, prüfe Vites `base`, die angeforderte Asset-URL und das Ausgabeverzeichnis. Wenn die App nie healthy wird, prüfe, ob der Service-Port `80` ist und ob keine alte Überschreibung des Startbefehls einen anderen Build-Pfad ausgewählt hat. + +Prüfe bei Seiten, die in der Suche erscheinen sollen, die anfängliche HTML-Antwort. Eine im Browser gerenderte Shell enthält möglicherweise nicht den Text, den eine Suchmaschine oder Answer Engine lesen soll. Wähle Prerendering oder ein Server-Framework, wenn du diesen Text in der Antwort benötigst. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen. diff --git a/_locales/de/framework-guides/static-routing.mdx b/_locales/de/framework-guides/static-routing.mdx new file mode 100644 index 0000000..ef44cf3 --- /dev/null +++ b/_locales/de/framework-guides/static-routing.mdx @@ -0,0 +1,107 @@ +--- +description: "Konfigurieren Sie statische Website-Routen auf Lizard: Stellen Sie erzeugtes HTML bereit, unterstützen Sie saubere URLs, geben Sie für fehlende Seiten HTTP 404 zurück und wählen Sie, wann ein SPA-Fallback sinnvoll ist." +--- + + + +# Statische Routen und 404-Fehler + +Eine Website mit erzeugten Inhalten sollte für jede Route deren HTML ausliefern und für eine fehlende Seite HTTP 404 zurückgeben. Neue lizardpack-Builds für Astro static, Docusaurus, VitePress, Hugo und SvelteKit adapter-static verwenden diese Richtlinie. React- und Vue-SPAs behalten den `index.html`-Fallback, den Browser-Router benötigen. + +Die benutzerdefinierte Konfiguration unten ist optional. Verwenden Sie sie für eine Routing-Richtlinie, die das erkannte Framework nicht bereitstellt. Bestehende Images behalten ihre alten Regeln, bis Sie sie neu bauen. + + + +## Wählen Sie die Routing-Richtlinie + +| App-Typ | Routenverhalten | +|---|---| +| React- oder Vue-SPA | Eine gültige Client-Route lädt `index.html`, danach rendert der Client-Router sie. | +| Erzeugte Dokumentation oder Inhalte | Eine Route wird zu ihrem erzeugten HTML aufgelöst; ein unbekannter Pfad gibt HTTP 404 zurück. | +| Serverseitig gerenderte App | Der Anwendungsserver löst Routen auf und gibt den Status zurück. | + +Eine SPA-Catch-all-Ansicht kann eine Meldung für fehlende Seiten anzeigen, aber Browser-Code kann den HTTP-Status der bereits gesendeten HTML-Antwort nicht ändern. Wenn Sie für eine SPA routenabhängigen HTTP-Status benötigen, verwenden Sie einen Server oder ein Prerendering-Routing-Setup, das weiß, welche Pfade existieren. + + + +## nginx für erzeugte Seiten konfigurieren + +Erstellen Sie `nginx.conf` im Anwendungsstamm: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + + location / { + try_files $uri $uri.html $uri/ =404; + } + + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +Dies unterstützt sowohl `guide.html`- als auch `guide/index.html`-Ausgabelayouts. Fügen Sie ein erzeugtes `404.html` ein, wenn Sie eine benutzerdefinierte Fehlerseite möchten. Lassen Sie andernfalls die `error_page`- und Exact-Location-Blöcke weg, um den Standard-Fehlertext von nginx zu verwenden. Behalten Sie in den Links und der Sitemap der Website einen kanonischen URL-Stil bei; diese Suchregel fügt keine kanonischen Weiterleitungen hinzu. + + + +## Website mit der Konfiguration bauen + +Verwenden Sie dieses vollständige Dockerfile für ein npm-Projekt mit einer eingecheckten Lockfile. Passen Sie die Standardwerte für `BUILD_SCRIPT` und `OUTPUT_DIR` an die folgende Tabelle an: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +ARG BUILD_SCRIPT=build +RUN npm run "$BUILD_SCRIPT" + +FROM nginx:alpine +ARG OUTPUT_DIR=dist +COPY --from=build /app/${OUTPUT_DIR}/ /usr/share/nginx/html/ +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +| Website | `BUILD_SCRIPT` | `OUTPUT_DIR` | +|---|---|---| +| Astro static | `build` | `dist` | +| Docusaurus | `build` | `build` | +| VitePress mit einem `docs/`-Stamm | `docs:build` | `docs/.vitepress/dist` | +| VitePress im Projektstamm | `docs:build` oder Ihr tatsächliches Skript | `.vitepress/dist` | +| SvelteKit mit adapter-static | `build` | `build` | +| Next.js export | `build` | `out` | +| Nuxt generate | `build` mit `nuxt generate` | `.output/public` | + +Verwenden Sie die Richtlinie für erzeugte Seiten nur, wenn die App diese Routendateien hat. Ein SvelteKit-SPA-Fallback benötigt zum Beispiel seine eigene Routing-Richtlinie. [Next.js statischer Export](/framework-guides/nextjs/static-export) enthält eine vollständige Anleitung mit einem Trailing-Slash-Layout. + +Schließen Sie Abhängigkeiten, Build-Ausgabe, `.git` und `.env*` in `.dockerignore` aus. Wenn der Build öffentliche Variablen benötigt, deklarieren Sie ihre `ARG`-Werte vor dem Build-Befehl. Kopieren Sie keine privaten Secrets in das Image oder die Browser-Ausgabe. + +Nach der [CLI-Einrichtung](/framework-guides#prepare-the-project) erstellen Sie einen Service mit `lizard add --service web` und stellen dann diesen Quellcode mit `lizard up --service web --port 80` bereit. Überspringen Sie den Schritt zum Hinzufügen, wenn der Service bereits existiert. Prüfen Sie bei einem bestehenden Service die [Reihenfolge der Build-Entscheidung](/concepts/build-pipeline#build-decision-order): Befehlsüberschreibungen können Vorrang vor dem Dockerfile haben. Eine Konfigurationsdatei allein ersetzt die erzeugte nginx-Konfiguration nicht; das Dockerfile muss sie in das Image kopieren. + + + +## HTTP-Antworten prüfen + +Setzen Sie `SITE_URL` auf die tatsächliche lokale Test-URL oder die bereitgestellte Origin und ersetzen Sie dann `/guide/` durch eine Seite, die existiert: + +```bash +SITE_URL=https://YOUR_PUBLIC_HOST +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/guide/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/this-page-does-not-exist" +``` + +Erwarten Sie 200 für echte Seiten und 404 für den fehlenden Pfad. Wenn eine gültige Route zu ihrer kanonischen Form weiterleitet, prüfen Sie die Weiterleitung und verifizieren Sie dann das Ziel. Testen Sie auch ein tatsächliches Asset und einen erfundenen `.js`-Pfad: Ein fehlendes Skript darf nicht die Startseite als HTML mit Status 200 zurückgeben. + +Öffnen Sie die innere Route abschließend direkt in einem Browser und laden Sie sie neu. Korrekte Client-Navigation allein kann einen Server-Routing-Fehler verbergen. Prüfen Sie vor der Veröffentlichung einer indexierten Website zusammen mit dem HTTP-Status auch die Einstellungen des Frameworks für kanonische URLs und die Sitemap. + +Unter [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) finden Sie die Deployment-Prüfungen vom 9. September 2026 und ihre Grenzen. + diff --git a/_locales/de/framework-guides/sveltekit.mdx b/_locales/de/framework-guides/sveltekit.mdx new file mode 100644 index 0000000..424ad11 --- /dev/null +++ b/_locales/de/framework-guides/sveltekit.mdx @@ -0,0 +1,110 @@ +--- +description: "Stelle SvelteKit mit adapter-node auf Lizard bereit. Konfiguriere den Produktions-Build, Port 3000, ORIGIN, Formularaktionen und den separaten Pfad für adapter-static." +--- + + + +# SvelteKit auf Lizard bereitstellen + +Verwende `@sveltejs/adapter-node`, um einen SvelteKit-Server für Lizard zu bauen. Dabei entsteht `build/`, das mit `node build` auf Port `3000` startet. Installiere und konfiguriere den Adapter ausdrücklich; ein Scaffold, das noch `adapter-auto` verwendet, richtet kein Node-Bereitstellungsziel ein. + +Beginne mit dem [vollständigen Quellcode-Beispiel](https://github.com/lizard-build/docs/tree/main/_examples/sveltekit), das die Konfiguration und Dateien enthält, die in dieser Anleitung verwendet werden. + + + +## Adapter konfigurieren + +```bash +npm install --save-dev @sveltejs/adapter-node +``` + +Behalte in `svelte.config.js` dein bestehendes Preprocess und andere Einstellungen bei, setze aber `kit.adapter` auf den Node-Adapter: + +```js +import adapter from '@sveltejs/adapter-node'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +Behalte nur den Bereitstellungs-Adapter, den du tatsächlich verwenden willst. Insbesondere kann eine ungenutzte Abhängigkeit `@sveltejs/adapter-static` im aktuellen Detektor den statischen Pfad auswählen, selbst wenn deine Konfiguration adapter-node importiert. + +| Einstellung | Wert | +|---|---| +| Build | `npm run build`, normalerweise `vite build` | +| Ausgabe | `build/` | +| Laufzeit | `node build` | +| Host und Port | `HOST=0.0.0.0`, `PORT=3000` | +| Service-Port | `3000` | + + + +## Produktionsserver testen + +```bash +npm ci +npm run build +HOST=0.0.0.0 PORT=3000 ORIGIN=http://localhost:3000 node build +``` + +Öffne eine servergerenderte Seite und sende eine Formularaktion ab, falls die App eine hat. Behalte den Standard-Ausgabepfad des Adapters für die in dieser Anleitung verwendete Erkennung bei. + + + +## Bereitstellen und die öffentliche Origin setzen + +Nach dem [CLI-Setup](/framework-guides#prepare-the-project): + +```bash +lizard init --name sveltekit-app +lizard add --service web +lizard up --service web --port 3000 +lizard ps --json +``` + +Setze `ORIGIN` auf die genaue öffentliche HTTPS-Origin aus der Bereitstellungsausgabe, ohne Pfad. Ersetze zum Beispiel diesen Platzhalter durch deine tatsächliche URL: + +```bash +lizard secrets set ORIGIN=https://YOUR_PUBLIC_HOST --service web +``` + +Verwende stattdessen die benutzerdefinierte Domain, wenn Besucher diese Origin verwenden werden. Prüfe Formulare nach der Variablenänderung erneut. Für mehrere erlaubte Origins oder Proxy-abgeleitete URLs lies die [Anleitung zum SvelteKit Node-Server](https://svelte.dev/docs/kit/adapter-node) und konfiguriere vertrauenswürdige Proxy-Header bewusst. + + + +## Verifizieren und Fehler beheben + +Lies Build- und Laufzeit-Logs mit `lizard logs --build --service web --json` und `lizard logs --service web --json`. Öffne direkt eine innere Route, sende ein Formular ab und rufe eine fehlende Route an. + +Wenn Formulare einen Fehler wegen einer Cross-Website-Übermittlung melden, prüfe `ORIGIN`, bevor du eine Sicherheitsprüfung deaktivierst. Wenn `node build` den Server nicht finden kann, prüfe den aktiven Adapter und den Ausgabepfad. Lasse Überschreibungen des Service-Befehls ungesetzt, um den lizardpack-Pfad zu verwenden. + + + +## Statische SvelteKit-Sites + +Eine App, die alle benötigten Seiten prerendern kann, kann `@sveltejs/adapter-static`, die Standard-Ausgabe `build/` und Service-Port `80` verwenden. Diese Ausgabe kann keine Server-Aktionen oder Endpunkte zur Request-Zeit ausführen. Konfiguriere Prerendering für die benötigten Routen; das Paket allein zu installieren reicht nicht aus. + +Installiere `@sveltejs/adapter-static` und ersetze den Adapter-Import in `svelte.config.js`: + +```js +import adapter from '@sveltejs/adapter-static'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +Für eine Website, deren Routen vollständig generiert werden können, füge dies zu `src/routes/+layout.js` hinzu: + +```js +export const prerender = true; +export const trailingSlash = 'always'; +``` + +Entferne ungenutzte Bereitstellungs-Adapter aus den Abhängigkeiten. Führe `npm run build` aus und prüfe, dass `build/` jede benötigte Seite enthält. Für die Standard-Ausgabe lasse Überschreibungen des Service-Befehls ungesetzt und stelle einen neuen Service auf Port `80` bereit. Neue Builds liefern das generierte HTML aus und geben HTTP 404 für fehlende Seiten zurück. Verwende für nginx nicht erneut den Port `3000` aus dem Server-Rezept. + +Verwende [statische Routen und 404-Seiten](/framework-guides/static-routing), um zwischen generierten HTML-Routen und einem SPA-Fallback zu wählen. Sieh dir den [SvelteKit Static Adapter](https://svelte.dev/docs/kit/adapter-static) für Framework-Optionen und Einschränkungen an. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen. + diff --git a/_locales/de/framework-guides/validation.mdx b/_locales/de/framework-guides/validation.mdx new file mode 100644 index 0000000..d740785 --- /dev/null +++ b/_locales/de/framework-guides/validation.mdx @@ -0,0 +1,72 @@ +--- +description: "Ergebnisse des Framework-Leitfadens aus 16 echten Lizard CLI-Bereitstellungen am 9. September 2026: getestete Versionen, Routen, Formulare, Migrationen, kanonische URLs und Grenzen." +--- + + + +# Testergebnisse des Framework-Leitfadens + +Am 9. September 2026 haben alle 16 Rezepte in 11 Frameworks einen lokalen Build und eine neue Cloud-Bereitstellung mit Lizard CLI 0.3.95 bestanden. Wir haben die veröffentlichte Einrichtung befolgt, für jedes Rezept ein neues Projekt und einen neuen Service erstellt und den Quellcode mit `lizard up` hochgeladen. Diese Ergebnisse decken die unten aufgeführten Versionen und kleinen Test-Apps ab. + +Der Cloud-Durchlauf bestand 100 Prüfungen von Routen, APIs und Formularen sowie 45 Prüfungen verknüpfter JavaScript- und CSS-Dateien. Django-Migrationen, ein Datenbankschreib- und -lesevorgang sowie die finalen Website-URLs von Docusaurus und Hugo wurden ebenfalls bestanden. + + + +## Getestete Rezepte + +| Rezept | Getestete Versionen | Port | Cloud-Prüfung | +|---|---|---|---| +| Next.js server | Next.js 16.3.4, React 19.2.8 | `3000` | Bestanden | +| Next.js statischer Export | Next.js 16.3.4, React 19.2.8 | `80` | Bestanden | +| React with Vite | React 19.2.8, Vite 8.2.2 | `80` | Bestanden | +| Vue with Vite | Vue 3.5.42, Vue Router 5.3.1, Vite 8.2.2 | `80` | Bestanden | +| Astro static | Astro 7.3.1 | `80` | Bestanden | +| Astro Node Server | Astro 7.3.1, Node adapter 11.1.5 | `3000` | Bestanden | +| Nuxt Node server | Nuxt 4.5.2 | `3000` | Bestanden | +| Nuxt generate | Nuxt 4.5.2 | `80` | Bestanden | +| SvelteKit Node-Server | SvelteKit 2.70.3, Svelte 5.57.0, adapter-node 5.5.7 | `3000` | Bestanden | +| SvelteKit static | SvelteKit 2.70.3, Svelte 5.57.0, adapter-static 3.0.10 | `80` | Bestanden | +| Docusaurus | Docusaurus 3.10.2 | `80` | Bestanden | +| VitePress, Docs-Root | VitePress 1.6.4 | `80` | Bestanden | +| VitePress, Projekt-Root | VitePress 1.6.4 | `80` | Bestanden | +| FastAPI | FastAPI 0.141.1, Uvicorn 0.52.4 | `8000` | Bestanden | +| Django | Django 6.1.1, Gunicorn 26.2.0, WhiteNoise 6.12.0, psycopg 3.3.5 | `8000` | Bestanden | +| Hugo | Hugo 0.165.0 (extended) | `80` | Bestanden | + +JavaScript-Builds verwendeten Node 22; Python-Builds verwendeten Python 3.13. Uploads liefen unter macOS ohne `COPYFILE_DISABLE`. Paketmanifeste und Lockfiles pinnen die oben genannten Versionen. Tags von Container-Images können sich unabhängig von einem Package-Lockfile ändern. + + + +## Was wir am 9. September geprüft haben + +- Wir haben die dokumentierten lokalen Build- und Server-Befehle in Linux-Containern ausgeführt und dann `lizard init`, `lizard add` und `lizard up` für jedes Rezept ausgeführt. Wir haben die Cloud-Build- und Laufzeit-Logs gelesen und den finalen Service-Status und Port geprüft. +- Wir haben die öffentliche Startseite, eine innere Route, ein echtes Asset, eine fehlende Seite und einen fehlenden JavaScript-Pfad angefordert. Statische Content-Sites lieferten echte 404-Antworten; React und Vue behielten ihr dokumentiertes SPA-Fallback bei. Beide VitePress-Layouts lieferten den richtigen Inhalt unter sauberen URLs. +- Wir haben API-Antworten zur Anfragezeit, POST-Handler, SvelteKit-Formularergebnisse und die Ablehnung eines Formulars von einer nicht vertrauenswürdigen Herkunft geprüft. Wir haben das bereitgestellte Next.js-Server-Aktion-Formular per HTTP mit seiner generierten action ID übermittelt und die Weiterleitung sowie den zurückgegebenen Wert geprüft. +- Wir haben Docusaurus und Hugo nach dem Setzen des generierten Hostnamens in der Konfiguration neu gebaut. Kanonische Docusaurus-URLs und beide Sitemaps verwendeten den öffentlichen Host. +- Wir haben Django-Migrationen zweimal gegen Managed Postgres ausgeführt, eine Testzeile geschrieben und gelesen, gesammelte statische Dateien ausgeliefert, ein gültiges CSRF-Formular akzeptiert und ein Formular ohne sein Token abgelehnt. + +Jedes Rezept verwendete ein separates Testprojekt mit unterschiedlichen Namen, um den Durchlauf isoliert zu halten. Workspace-, Region- und JSON-Flags machten den Testkontext explizit. Service-Overrides für Build, Start und Dockerfile-Pfad blieben ungesetzt. Nur die Rezepte Next.js statischer Export, Nuxt generate und Django lieferten die in ihren Leitfäden dokumentierten Dockerfiles mit. Die Tests für Docusaurus, VitePress, Hugo und SvelteKit Node enthielten die [veröffentlichten Quellcodebeispiele](https://github.com/lizard-build/docs/tree/main/_examples). + + + +## Browser-Prüfungen + +Der Durchlauf vom 9. September bestätigte einen React-Button-Klick im Browser. Die Browser-Verbindung lieferte danach wiederholte Timeouts bei Navigation und Seitenlesevorgängen zurück, daher beansprucht dieser Durchlauf **keinen** erneuten erfolgreichen Browser-Test für alle 16 Rezepte. HTTP-Routen- und Formularprüfungen wurden unabhängig bestanden. + +Der Durchlauf vom 7. September umfasste Reloads direkter Routen, React-Interaktion, Vue-Router-Navigation, Next.js Server Actions und SvelteKit-Formularübermittlungen in einem Browser. Diese bleiben Ergebnisse dieses früheren Durchlaufs. + + + +## Korrekturen seit dem ersten Durchlauf + +Der Durchlauf vom 7. September fand fehlende Schritte zur Service-Erstellung, einen Nuxt-Static-Preset-Mismatch, Defekte im statischen Routing, macOS-Archivmetadaten, Exit-Codes bei fehlgeschlagenen Builds und Fehler bei Port-Änderungen. Die Leitfäden enthalten jetzt `lizard add` und die korrigierte statische Nuxt-Einrichtung. + +Die erneute Prüfung des statischen Routings vom 8. September wurde ohne benutzerdefinierte Dockerfiles für Astro static, SvelteKit static, Docusaurus, Hugo und beide VitePress-Layouts bestanden. Neue Builds enthalten diese Routing-Regeln; vorhandene Images benötigen einen Neubau. + +Lizard CLI 0.3.95 enthält die Korrekturen für Archive und Exit-Codes bei fehlgeschlagenen Builds. Die Produktionsprüfungen vom 9. September verifizierten außerdem Service-Port-Änderungen und den Erhalt eines expliziten Ports während Upload und Neubau. Siehe [known issues](/platform/known-issues) für die Release Hinweise und verbleibenden Grenzen. + + + +## Grenzen dieser Ergebnisse + +Diese Prüfungen decken Quellcode-Uploads und die dokumentierten Modi ab. Sie belegen keine Unterstützung für jedes Plugin, jeden Adapter, jedes Theme, jede Framework-Version, jeden GitHub-Bereitstellungspfad, jedes Datenbank-Recovery-Verfahren oder Workloads mit mehreren Replikaten. Djangos kleine Test-App meldet weiterhin Sicherheitswarnungen von `check --deploy`; sie ist keine vollständige Sicherheitskonfiguration für die Produktion. Diese Tests messen weder Suchrankings noch AI-Zitationen. Prüfen Sie vor dem Release die Routen und Datenoperationen Ihrer eigenen App. diff --git a/_locales/de/framework-guides/vitepress.mdx b/_locales/de/framework-guides/vitepress.mdx new file mode 100644 index 0000000..3fa46c7 --- /dev/null +++ b/_locales/de/framework-guides/vitepress.mdx @@ -0,0 +1,78 @@ +--- +description: "Stelle VitePress auf Lizard bereit mit docs:build, dem korrekten Verzeichnis .vitepress/dist, nginx und Port 80. Konfiguriere saubere URLs und prüfe Dokumentationsrouten und 404er." +--- + + + +# VitePress auf Lizard bereitstellen + +Lizard kann eine VitePress-Dokumentationswebsite bauen und das generierte HTML über nginx auf Port `80` ausliefern. Stimme npm-Skript und Ausgabeverzeichnis auf dein Docs-Root ab: `vitepress build docs` schreibt nach `docs/.vitepress/dist`, während `vitepress build` nach `.vitepress/dist` schreibt. + +Starte mit dem [vollständigen Quellcodebeispiel](https://github.com/lizard-build/docs/tree/main/_examples/vitepress), das die Konfiguration und Dateien enthält, die in dieser Anleitung verwendet werden. + + + +## Build-Skript festlegen + +Für Markdown-Dateien in `docs/` behalte diese Skripte in `package.json` bei: + +```json +{ + "scripts": { + "docs:dev": "vitepress dev docs", + "docs:build": "vitepress build docs", + "docs:preview": "vitepress preview docs" + } +} +``` + +| Einstellung | Wert in dieser Anleitung | +|---|---| +| Build | `npm run docs:build` | +| Docs root | `docs/` | +| Output | `docs/.vitepress/dist/` | +| Production server | nginx | +| Service-Port | `80` | + +Die Erkennung findet ein Skript, das `vitepress build` enthält, und verwendet dessen Root-Argument. Halte dieses Skript direkt und eindeutig. Shell-Wrapper, mehrere passende Skripte oder ein benutzerdefiniertes `outDir` erfordern eine explizite Build-Konfiguration oder ein Dockerfile. + + + +## Website lokal prüfen + +```bash +npm ci +npm run docs:build +npm run docs:preview +``` + +Prüfe eine innere Markdown-Seite und ein Asset. Mit `cleanUrls: true` verlinkt VitePress auf Routen ohne Dateiendung; der Produktionsserver muss diese URLs zu den generierten HTML-Dateien auflösen. Setze `base` auf den tatsächlichen Pfadpräfix oder `/` für die Domain-Wurzel. Siehe [VitePress deployment](https://vitepress.dev/guide/deploy). + + + +## Bereitstellen + +Führe nach dem [CLI-Setup](/framework-guides#prepare-the-project) den Befehl aus dem Verzeichnis aus, das `package.json` enthält, nicht von innerhalb von `docs/`: + +```bash +lizard init --name vitepress-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Schließe die VitePress-Konfiguration, Markdown, Quell-Assets, das Package-Manifest und die Lockfile ein. Schließe lokale Abhängigkeiten, generierte Ausgabe, Caches und Secrets aus. Setze `vitepress dev` oder `vitepress preview` nicht als Startbefehl des Service. + + + +## Saubere Routen und HTTP-Status prüfen + +Neue VitePress-Builds lösen Routen ohne Dateiendung zu ihren generierten `.html`-Dateien auf und geben für fehlende URLs HTTP 404 zurück. Lass Befehlsüberschreibungen deaktiviert, um diesen Erkennungspfad zu verwenden. Für die Standardausgabe ist kein benutzerdefiniertes Dockerfile nötig. Siehe [Statische Routen und 404er](/framework-guides/static-routing) für benutzerdefiniertes Routing. + +Prüfe eine saubere URL direkt und lade sie neu. Rufe einen nicht existierenden Pfad auf und bestätige HTTP 404. Wenn ein älteres Image für fehlende Pfade die Startseite ausliefert, baue den Service neu, damit die aktuellen Routing-Regeln übernommen werden. + +Wenn der Build `Missing script: build` meldet, prüfe, dass der ausgewählte Pfad die VitePress-Erkennung verwendet und keine Überschreibung des Service-Befehls diese ersetzt. Wenn der Build erfolgreich ist, nginx aber keine Doku ausliefert, vergleiche das Docs-Root des Skripts mit dem kopierten Ausgabeverzeichnis. Baue nach Änderungen an Inhalt oder Konfiguration neu. + +Siehe [Getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Grenzen. + diff --git a/_locales/de/framework-guides/vue.mdx b/_locales/de/framework-guides/vue.mdx new file mode 100644 index 0000000..f46c995 --- /dev/null +++ b/_locales/de/framework-guides/vue.mdx @@ -0,0 +1,70 @@ +--- +description: "Stelle eine mit Vite gebaute Vue-App auf Lizard bereit. Konfiguriere dist-Ausgabe, Port 80, den History-Modus von Vue Router, öffentliche Umgebungsvariablen und Prüfungen für die Produktion." +--- + + + +# Vue mit Vite auf Lizard bereitstellen + +Stelle eine mit Vite gebaute Vue-App als statischen Webservice auf Lizard bereit. Der Build erzeugt `dist/`, und nginx liefert die Dateien auf Port `80` aus. Für Nuxt-Server-Rendering und Server-Routen nutze den [Nuxt-Leitfaden](/framework-guides/nuxt). + + + +## Projekt vorbereiten + +Führe den Vorgang im Verzeichnis der Vue-App aus, mit `package.json`, einer Lockfile und der Vite-Konfiguration. Behalte das Build-Skript des Scaffolds bei, einschließlich `vue-tsc`, wenn damit dein TypeScript-Code geprüft wird. Der Build muss erfolgreich abgeschlossen werden, indem das Vite-Bundle in `dist/` erzeugt wird. + +| Einstellung | Wert | +|---|---| +| Build | `npm run build` | +| Output | `dist/` | +| Start command | Keine für den Erkennungspfad statischer Bereitstellung | +| Service-Port | `80` | + +Behalte `base: '/'` für eine Website an der Domain-Wurzel bei. Wenn du ein Pfadpräfix verwendest, richte die base von Vite an der Router-Basis und der URL aus, unter der die App tatsächlich läuft. Ein benutzerdefiniertes Ausgabeverzeichnis benötigt ein Dockerfile, das dieses Verzeichnis kopiert. + + + +## Build lokal prüfen + +```bash +npm ci +npm run build +npm run preview +``` + +Nutze die lokale Vorschau-URL, um eine Komponente zu prüfen, die Daten abruft, und eine Seite, die über den Router erreicht wird. `vite preview` ist für diese lokale Prüfung gedacht; nginx liefert die Produktionsdateien aus. Informationen zum Build-Output und zum Verhalten der Vorschau findest du im [Deployment-Leitfaden von Vite](https://vite.dev/guide/static-deploy.html). + + + +## Bereitstellen + +Stelle nach dem [CLI-Setup](/framework-guides#prepare-the-project) das aktuelle Quellverzeichnis bereit: + +```bash +lizard init --name vue-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Schließe lokale Abhängigkeiten, `dist/` und `.env`-Dateien vom Upload aus. Ohne bestehende Befehlsüberschreibungen erkennt lizardpack Vite und erstellt das statische Image. Füge `npm run dev` nicht als Startbefehl des Service hinzu. + + + +## Vue Router History-Modus + +Wenn deine App `createWebHistory` verwendet, muss ihr Server direkte Anfragen an Client-Routen verarbeiten können. Das standardmäßige statische Image liefert `index.html` aus, wenn keine Datei gefunden wird, sodass `/account` Vue Router bei einem harten Neuladen erreichen kann. Stimme die Router-Basis auf die Vite-base ab, zum Beispiel mit `createWebHistory(import.meta.env.BASE_URL)`. Siehe [History-Modi von Vue Router](https://router.vuejs.org/guide/essentials/history-mode.html). + +Teste sowohl die Navigation von der Startseite als auch das Öffnen von `/account` in einem neuen Tab. Füge eine Catch-all-Ansicht für fehlende Client-Routen hinzu. Der Server-Fallback gibt selbst für unbekannte Pfade HTTP 200 zurück; suchmaschinenfreundliche 404-Antworten liefert er nicht. Lies [statische Routen und 404er](/framework-guides/static-routing), bevor du dieses Setup für eine indexierte Content-Website verwendest. + + + +## Variablen und API-Anfragen + +Vite schreibt `VITE_*`-Werte während des Builds in das Browser-Bundle. Verwende sie nur für öffentliche Werte, etwa die öffentliche HTTPS-URL deiner API. Setze sie über [Variablen und Secrets](/variables) und prüfe dann die tatsächliche Netzwerkanfrage der neu gebauten App. Ein reiner Laufzeit-Neustart kann keinen Wert in bereits gebautem JavaScript ersetzen. + +Wenn Anfragen nur nach dem Deployment fehlschlagen, prüfe CORS auf der API und bestätige, dass der Browser nicht `localhost` oder einen privaten Backend-Hostnamen aufruft. Wenn das HTML lädt, aber Assets fehlschlagen, prüfe die base von Vite und die Asset-Pfade. Für Seiten, die HTML benötigen, bevor JavaScript läuft, wähle Nuxt-Rendering oder einen expliziten Prerendering-Schritt. + +Siehe [getestete Versionen und Cloud-Ergebnisse](/framework-guides/validation) für die Deployment-Prüfungen vom 9. September 2026 und ihre Grenzen. diff --git a/_locales/de/getting-started.mdx b/_locales/de/getting-started.mdx new file mode 100644 index 0000000..5ad00d8 --- /dev/null +++ b/_locales/de/getting-started.mdx @@ -0,0 +1,134 @@ +--- +description: "Installieren Sie die lizard CLI, melden Sie sich an und stellen Sie Ihre erste App in wenigen Minuten aus einem GitHub-Repo oder einem lokalen Ordner bereit, und fügen Sie dann eine Datenbank hinzu." +--- + + + +# App-Schnellstart + +Stellen Sie Ihre erste App in wenigen Minuten auf Lizard bereit. Sie benötigen Node.js 18+ und npm — ein Lizard-Konto wird automatisch erstellt, wenn Sie zum ersten Mal `lizard login`. Sie installieren die CLI, melden sich an und stellen dann bereit — entweder direkt aus einem GitHub-Repo oder aus einem lokalen Verzeichnis. + + + +## 1. Die CLI installieren + +Installieren Sie die `lizard`-Binärdatei global über npm: + +```bash +npm install -g @lizard-build/cli +``` + +Prüfen Sie, ob sie sich in Ihrem `PATH` befindet: + +```bash +lizard --version +``` + +> **Verwenden Sie nicht `npx`.** Verwenden Sie immer die global installierte `lizard`-Binärdatei. Beim Ausführen von `npx @lizard-build/cli` wird eine Wegwerfkopie geladen, deren Version von der Plattform abweichen kann. Aktualisieren Sie sie später direkt mit `lizard upgrade`. + +> **Berechtigungsfehler (EACCES)?** Verwenden Sie nicht `sudo`. Setzen Sie stattdessen für npm ein Präfix in einem Verzeichnis, das Ihrem Benutzer gehört: +> ```bash +> mkdir -p ~/.npm-global +> npm config set prefix ~/.npm-global +> echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc && source ~/.zshrc +> npm install -g @lizard-build/cli +> ``` + + + +## 2. Anmelden + +```bash +lizard login +``` + +Dadurch wird Ihr Browser zur Authentifizierung geöffnet und Sie kehren nach der Bestätigung in Ihr Terminal zurück. In CI oder anderen nicht interaktiven Umgebungen authentifizieren Sie sich stattdessen mit einem Token: + +```bash +export LIZARD_TOKEN=lzd_xxx +# or +lizard login --token lzd_xxx +``` + +Sie können jederzeit prüfen, wer Sie sind: + +```bash +lizard whoami +``` + + + +## 3. Bereitstellen + +Wählen Sie den Weg, der zu dem Ort passt, an dem Ihr Code liegt. + + + +### Option A — Ein GitHub-Repo bereitstellen (empfohlen) + +Wenn Ihr Code auf GitHub liegt, erstellen Sie einen Service direkt aus dem Repo. Lizard klont es, erkennt den Stack automatisch, baut ihn und gibt eine Live-URL zurück: + +```bash +lizard add -r your-org/your-app +``` + +Pushes auf den verfolgten Branch lösen ab dann automatisch eine erneute Bereitstellung aus. Bei privaten Repos verbinden Sie zuerst die GitHub App: + +```bash +lizard git connect +``` + + + +### Option B — Lokalen Code bereitstellen + +Laden Sie im Projektverzeichnis den aktuellen Ordner hoch und stellen Sie ihn bereit (berücksichtigt `.gitignore`): + +```bash +lizard up +``` + +Wenn das Verzeichnis noch nicht mit einem Projekt verknüpft ist, erstellt oder wählt `up` es interaktiv aus. In CI verknüpfen Sie es vorher explizit mit `lizard init --name my-project`. + +In beiden Fällen erhalten Sie nach Abschluss des Builds eine generierte URL wie `https://your-app-production.onlizard.com`. + + + +## 4. Build und Ausführung beobachten + +```bash +lizard ps # services in the project, with status + URL +lizard logs # last runtime log lines +lizard logs --build # the most recent build's logs +lizard open # open the project in the dashboard +``` + + + +## 5. Eine Datenbank hinzufügen (optional) + +Stellen Sie ein Managed Postgres bereit und referenzieren Sie es aus Ihrem Service: + +```bash +lizard add postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service your-app +lizard redeploy --service your-app +``` + +Die Referenz `${{postgres.DATABASE_URL}}` wird beim Bereitstellen aufgelöst und automatisch zusammen mit dem Add-on rotiert. Siehe [Managed Addons](/addons). + + + +## Nächste Schritte + +- **[Grundkonzepte](/concepts/architecture)** — Projekte, Services und die Build-Pipeline verstehen. +- **[Bereitstellung über GitHub](/deploy/github)** — Branches, Monorepos und automatische erneute Bereitstellungen. +- **[Variablen & Secrets](/variables)** — Geltungsbereich und Priorität. +- **[Netzwerk](/networking)** — Ihren eigenen Hostnamen mit automatischem TLS verbinden. +- **[Eine App bereitstellen, die Ihre AI IDE erstellt hat](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production)** — dieselben drei Schritte, nur stattdessen an einen Agenten übergeben, für eine in Google Antigravity geschriebene App. + + + +## Hosting-Kosten + +Lizard verwendet [pay as you go](/platform/billing) ohne monatliches Abonnement. Die Ressourcennutzung wird mit Ihrem Kontoguthaben verrechnet. Gekaufte Guthaben verfallen nicht; Testguthaben schon. Prüfen Sie vor der Bereitstellung [die Preise](https://lizard.build/pricing) und Ihre Kontolimits. diff --git a/_locales/de/guides/_meta.ts b/_locales/de/guides/_meta.ts new file mode 100644 index 0000000..c3bc97c --- /dev/null +++ b/_locales/de/guides/_meta.ts @@ -0,0 +1,2 @@ +export default { index: "Leitfaden auswählen", 'deploy-from-coding-agent': "Aus einem Coding-Agenten deployen", 'deploy-mcp-server': "Einen Remote-MCP-Server hosten", 'telegram-bot': "Einen Telegram-Bot ausführen", umami: "Umami ausführen", flowise: "Flowise mit PostgreSQL ausführen", validation: "Testergebnisse" }; + diff --git a/_locales/de/guides/deploy-from-coding-agent.mdx b/_locales/de/guides/deploy-from-coding-agent.mdx new file mode 100644 index 0000000..9f58714 --- /dev/null +++ b/_locales/de/guides/deploy-from-coding-agent.mdx @@ -0,0 +1,139 @@ +--- +description: "Stelle eine App aus Claude Code, Codex oder Cursor mit Lizard Skill und Lizard CLI bereit. Wähle GitHub oder lokalen Quellcode, verbinde eine Datenbank und überprüfe das Ergebnis." +--- + + + +# Bereitstellung aus einem Coding-Agent + +Ein Coding-Agent kann Lizard Skill und Lizard CLI verwenden, um die von ihm erstellte App bereitzustellen. Der Agent liest die Anleitung der installierten CLI, prüft das Zielprojekt, führt den Build aus und kontrolliert das Ergebnis. Dafür ist kein separater MCP-Transport erforderlich. + + + +## Bevor du beginnst + +Du brauchst eine funktionsfähige Anwendung, die Berechtigung, sie bereitzustellen, und ein Konto bei Lizard. Die Anwendung muss auf `0.0.0.0` und dem konfigurierten Port lauschen. Führe ihre lokalen Prüfungen aus, bevor du einen Cloud-Build startest. + + + +## Gib dem Agenten die aktuelle Anleitung + +```bash +npm install -g @lizard-build/cli +lizard skills get core --json +lizard --help --json +``` + +Lizard Skill lädt Anweisungen, die zur installierten CLI passen. Lies für einen bestimmten Befehl dessen Schema, statt Flags zu raten: + +```bash +lizard up --help --json +lizard service set --help --json +``` + +Ein nützlicher Prompt ist: + +> Stelle diese App mit Lizard bereit. Lies die Anleitung der installierten CLI, prüfe das verknüpfte Projekt und den Service, führe die Prüfungen der App aus und zeige das Build-Ergebnis sowie eine funktionierende URL. Frage nach, bevor du einen bestehenden Produktions-Service änderst oder Daten löschst. + + + +## Lokalen Quellcode bereitstellen + +Für einen vollständigen Test verwende das Beispiel [agent-app-Beispiel](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/agent-app). Es nutzt Node.js 22 und `pg` 8.16.3, lauscht auf Port 3000 und liest eine Zeile aus Managed Postgres. Beim Start werden die Demo-Tabelle und die Demo-Zeile erstellt, falls sie nicht vorhanden sind. Für eine größere Anwendung solltest du deinen eigenen Migrationsprozess verwenden. + +Kopiere das Beispiel in ein eigenes Verzeichnis und führe seine lokalen Prüfungen aus: + +```bash +npm ci +npm run check +lizard status --json +``` + +Damit wird die JavaScript-Syntax geprüft. Die Prüfungen für Datenbank und öffentliches HTTP erfolgen nach der Bereitstellung. Wenn dieses Verzeichnis bereits verknüpft ist, prüfe, ob es das vorgesehene Projekt ist. Für ein neues Testprojekt: + +```bash +lizard init --name agent-example --json +lizard add --service api --json +lizard add postgres --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api --json +lizard up --service api --port 3000 --json +``` + +Verwende den tatsächlichen Namen der Datenbank, falls er nicht `postgres` ist. Lass die Referenz in Anführungszeichen, damit die lokale Shell sie nicht expandiert. Konfiguriere sie vor der ersten Bereitstellung. Melde dich nur mit `lizard login` an, wenn ein Befehl meldet, dass eine Authentifizierung erforderlich ist. + +Der Upload-Pfad ist für dieses kopierte Beispiel beabsichtigt. Für eine Anwendung, die bereits in GitHub liegt, verwende stattdessen den nächsten Abschnitt. Unter macOS mit Lizard CLI 0.3.92 führe `COPYFILE_DISABLE=1 lizard up --service api --port 3000 --json` aus, um AppleDouble-Metadaten auszuschließen. In dieser CLI-Version kann ein fehlgeschlagener Build trotzdem mit Code 0 enden: Prüfe das Ereignis `failed`/`deployed` im Terminal und verifiziere die Anwendung. Siehe [bekannte Probleme](/platform/known-issues). + + + +## Aus GitHub bereitstellen + +Verwende diesen Weg, wenn die Anwendung ein GitHub-Repository hat. Prüfe zuerst das Remote: + +```bash +git remote get-url origin +lizard status --json +lizard ps --json +``` + +Verwende ein verknüpftes Testprojekt oder erstelle eines mit `lizard init --name YOUR_PROJECT_NAME`. Hänge das Repository an, ohne einen Build zu starten, damit Zeit bleibt, seine Umgebung zu konfigurieren: + +```bash +lizard add --repo YOUR_ORG/YOUR_REPO --name api-git --no-deploy --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api-git --json +``` + +Stelle zuerst Managed Postgres bereit, wenn dieses Projekt es noch nicht hat. Diese Abfolge verwendet dasselbe Node.js-Beispiel wie oben. Für ein Repository mit dieser App in einem Unterverzeichnis oder auf einem anderen Branch konfiguriere es vor der Bereitstellung: + +```bash +lizard service set api-git --set branch=YOUR_BRANCH --set rootDirectory=YOUR_APP_DIRECTORY --set containerPort=3000 --json +lizard redeploy --service api-git --json +``` + +Für eine App im Repository-Root auf `main` lasse den Befehl `service set` weg. Setze den korrekten Port, falls deine Anwendung einen anderen verwendet. Wenn das Repository für Lizard nicht verfügbar ist, verbinde die GitHub-App; ersetze diesen Weg nicht stillschweigend durch einen Upload. + +Für spätere Aktualisierungen eines bestehenden GitHub-Service verwende `lizard redeploy --service api-git` oder pushe in den verfolgten Branch, wenn Auto-Bereitstellen aktiviert ist. `lizard up` stellt einen Service auf Upload-Quellcode um. Das Ändern von Build-Einstellungen bei einem bereits laufenden Service kann einen eigenen Build auslösen; prüfe die Ereignisse, bevor du einen weiteren anforderst. + + + +## Ergebnis überprüfen + +Lies Build- und Laufzeit-Logs getrennt: + +```bash +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +Verwende für den GitHub-Pfad `api-git` statt `api`. Setze `APP_URL` auf die von der CLI gemeldete HTTPS-URL und führe dann Folgendes aus: + +```bash +curl --fail "$APP_URL/health" +curl --fail "$APP_URL/data" +``` + +Die erste Antwort ist `App ready`. Die zweite ist `{"value":"database-connected"}`. Ein Build allein beweist nicht, dass die Datenbankreferenz aufgelöst wurde. Das Beispiel stellt nur diese feste Demo-Zeile bereit, keine API zur Datenbankverwaltung. + +Für diesen Test-Service prüfe einen Laufzeit-Neustart: + +```bash +lizard restart --service api --json +``` + +Warte, bis der Service in `lizard ps --json` wieder zu `running` zurückkehrt, und wiederhole beide HTTP-Anfragen. Ein Laufzeit-Log-Tail kann leer sein; die HTTP-Antwort ist die Anwendungsprüfung. Die Zeile wird in Managed Postgres gespeichert; der Service-Prozess speichert sie nicht. Um die Wiederverwendung vorhandener Daten zu prüfen, aktualisiere die Demo-Zeile vor dem Neustart im Datenbankeditor auf einen eindeutigen Wert und bestätige anschließend, dass `/data` diesen Wert zurückgibt. + +`logs --json` gibt ein Log-Tail zurück und beendet sich. Lies [Speicherung und Wiederherstellung](/platform/storage-and-recovery), bevor du echte Anwendungsdaten änderst. + + + +## Wenn die Bereitstellung fehlschlägt + +Verwende den Exit-Code und den JSON-Fehler des fehlgeschlagenen Befehls. Ein Compile-Fehler, ein Prozess, der beendet wird, und ein nicht erreichbarer Port erfordern unterschiedliche Korrekturen. Siehe [JSON und Automatisierung](/cli/json) und [Service wird nie healthy](/deploy/troubleshooting/service-never-healthy). `redeploy` ist ein neuer Build, kein Rollback auf eine ältere Version. + + + +## Limits und Kosten + +Ein Agent kann über dieselbe CLI wie eine Person kostenpflichtige Ressourcen erstellen. Prüfe [Limits](/platform/limits) und [Preise](https://lizard.build/pricing), und beschränke Credentials auf das Projekt und die Services, die es benötigt. + +Siehe [Ergebnisse der Szenariotests](/guides/validation) für geprüfte Versionen, Cloud-Ergebnisse und verbleibende Limits. diff --git a/_locales/de/guides/deploy-mcp-server.mdx b/_locales/de/guides/deploy-mcp-server.mdx new file mode 100644 index 0000000..0f4bd8a --- /dev/null +++ b/_locales/de/guides/deploy-mcp-server.mdx @@ -0,0 +1,116 @@ +--- +description: "Hosten Sie einen Remote-MCP-Server auf Lizard mit Streamable HTTP, Bearer-Token-Prüfungen, einem Health-Endpunkt und einem Client, der einen Tool-Aufruf verifiziert." +--- + + + +# Einen Remote-MCP-Server hosten + +Stellen Sie einen MCP-Server als HTTP-Anwendung bereit, wenn Clients eine Remote-URL benötigen. Dieses Beispiel stellt ein arithmetisches Tool bereit, prüft ein Bearer-Token und bietet einen Health-Endpunkt an. Es verwendet Streamable HTTP; ein lokaler `stdio`-Server kann Remote-Clients nicht allein bedienen. + + + +## Bevor Sie beginnen + +Sie benötigen Node.js 22, Lizard CLI, ein Projekt, das Sie bereitstellen können, und einen MCP-Client, der ein konfiguriertes Bearer-Token akzeptiert. Das Beispiel verwendet `@modelcontextprotocol/sdk` 1.30.0 im zustandslosen Modus. Es bietet weder OAuth-Login noch Browserzugriff oder einen Identitätsanbieter. + +Die ausführbaren Dateien befinden sich in [remote-mcp-node](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/remote-mcp-node). Verwenden Sie die eingecheckte Lockfile. Der lokale Smoke-Test prüft Initialisierung, Tool-Erkennung, einen Tool-Aufruf und die Ablehnung ohne gültiges Token. Eine Deployment-Prüfung muss außerdem den öffentlichen Proxy und den TLS-Pfad bestätigen. + + + +## Lokal ausführen + +Aus dem Beispielverzeichnis: + +```bash +npm ci +npm test +node issue-token.mjs +export MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" +export MCP_ALLOWED_HOSTS=127.0.0.1,localhost +npm start +``` + +Das erzeugte Token läuft nach einer Stunde ab. Der private Signaturschlüssel wird nicht gespeichert. Verwenden Sie für ein dauerhaftes Deployment Ihren eigenen Token-Issuer und Rotationsprozess; bewahren Sie dessen privaten Schlüssel außerhalb des Servers auf. + +In einem anderen Terminal: + +```bash +export MCP_URL=http://127.0.0.1:8000/mcp +export MCP_TOKEN="$(cat .mcp-token)" +node client.mjs +``` + +Der Client prüft Initialisierung, Tool-Erkennung und das Ergebnis `5` und gibt dann `MCP initialize, tools/list and tools/call passed: 5` aus. `/health` gibt `ok` zurück; eine Anfrage an `/mcp` ohne gültiges Token gibt `401` zurück. + + + +## Die Anwendung bereitstellen + +Behalten Sie die Dockerfile und die Lockfile des Beispiels bei. Aus dem Verzeichnis, das sie enthält: + +```bash +lizard init --name mcp-example +lizard add --service mcp +lizard domain --service mcp --json +``` + +Melden Sie sich mit `lizard login` an, wenn ein Befehl meldet, dass eine Authentifizierung erforderlich ist. `init` verknüpft das Projekt; `add` erstellt den benannten Service. Der Domain-Befehl weist seinen Hostnamen vor dem Deployment zu. Verwenden Sie unten die zurückgegebene `hostname`, ohne `https://` oder einen Pfad: + +```bash +lizard secrets set MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" --service mcp +lizard secrets set MCP_ALLOWED_HOSTS=YOUR_SERVICE_HOSTNAME --service mcp +``` + +Setzen Sie beide Werte vor dem ersten Deployment. Führen Sie dann Folgendes aus: + +```bash +lizard up --service mcp --port 8000 +lizard logs --build --service mcp --json +lizard logs --service mcp --json +lizard ps --json +``` + +Unter macOS mit Lizard CLI 0.3.92 verwenden Sie `COPYFILE_DISABLE=1 lizard up --service mcp --port 8000`, um AppleDouble-Metadaten aus dem Archiv auszuschließen. Eine spätere CLI-Version kann die Archivkorrektur enthalten. Prüfen Sie das letzte Deployment-Ereignis und den öffentlichen Endpunkt; verlassen Sie sich nach einem fehlgeschlagenen Build bei dieser CLI-Version nicht allein auf den Exit-Code. `server.mjs` lauscht auf `0.0.0.0` und liest `PORT`, mit 8000 als Standardwert. Der Bereitstellen-Befehl setzt den Service-Port auf 8000. Konfigurieren Sie den öffentlichen Schlüssel als mehrzeiligen Umgebungswert; laden Sie weder den privaten Signaturschlüssel noch die Token-Datei hoch. + + + +## Den öffentlichen Endpunkt verifizieren + +Setzen Sie `MCP_URL` auf `https://YOUR_SERVICE_HOSTNAME/mcp`, halten Sie ein gültiges Token in der Client-Umgebung vor und führen Sie `node client.mjs` aus. Verifizieren Sie alle drei Ergebnisse: + +1. `/health` gibt `200` über HTTPS zurück. +2. `/mcp` weist einen Client ohne gültiges Token zurück. +3. Der authentifizierte Client listet Tools auf und ruft `add` auf und gibt dabei `5` zurück. + +Ein gesunder Prozess allein beweist nicht, dass der MCP-Handshake oder die gestreamte Antwort über den öffentlichen Proxy funktioniert. + + + +## Fehlerbehebung + +| Ergebnis | Prüfen | +|---|---| +| Prozess beendet sich beim Start | `MCP_PUBLIC_KEY` muss den öffentlichen PEM-Schlüssel enthalten; `MCP_ALLOWED_HOSTS` muss den Hostnamen des Service enthalten. | +| `401` | Das Token muss RS256 verwenden, mit Issuer und Audience `mcp-example` übereinstimmen und darf nicht abgelaufen sein. | +| `403` | Der Hostname der Anfrage muss mit `MCP_ALLOWED_HOSTS` übereinstimmen. Browser-Origin-Anfragen sind in diesem Beispiel nicht aktiviert. | +| `405` mit einem gültigen Token | Dieser zustandslose MCP-Endpunkt akzeptiert Protokollanfragen per POST. Verwenden Sie einen MCP-Client. Ein Browser-GET ohne Token gibt zuerst `401` zurück. | +| Lokaler Test erfolgreich, aber Remote-Aufruf schlägt fehl | Prüfen Sie Port, HTTPS, Response-Streaming und Proxy-Timeouts. | + + + +## Grenzen und Kosten + +Dieses Beispiel hält weder Benutzersitzungen noch dauerhafte Dateien im Serverspeicher vor. Fügen Sie für dauerhaften Anwendungszustand eine Datenbank hinzu und prüfen Sie den Zugriff pro Benutzer, bevor Sie private Tools bereitstellen. Für Clients, die OAuth-Discovery oder interaktiven Login benötigen, fügen Sie einen unterstützten OAuth-Anbieter hinzu, statt dieses Test-Token zu verteilen. + +Ein HTTP-Prozess kann zwischen Aufrufen aktiv bleiben. Prüfen Sie [pricing](https://lizard.build/pricing), [limits](/platform/limits) und die gemessene CPU-/Speicherauslastung; eine leere Anfragewarteschlange bedeutet nicht, dass keine Kosten anfallen. + + + +## Nächste Schritte + +- [Umgebungsreferenzen](/variables/references) +- [Deployment-Wiederherstellung](/concepts/deployments) +- [MCP TypeScript SDK-Serverleitfaden](https://ts.sdk.modelcontextprotocol.io/server) + +Unter [Szenariotestergebnisse](/guides/validation) finden Sie geprüfte Versionen, Cloud-Ergebnisse und verbleibende Einschränkungen. diff --git a/_locales/de/guides/flowise.mdx b/_locales/de/guides/flowise.mdx new file mode 100644 index 0000000..9f5012f --- /dev/null +++ b/_locales/de/guides/flowise.mdx @@ -0,0 +1,165 @@ +--- +description: "Stelle Flowise mit PostgreSQL bereit, bewahre seinen Verschlüsselungsschlüssel für Anmeldedaten auf und prüfe gespeicherte Flows nach Neustarts und Upgrades." +--- + + + +# Flowise mit PostgreSQL ausführen + +Diese Anleitung richtet einen Flowise-Service auf Lizard ein, mit PostgreSQL für Flows, Konten und verschlüsselte Anmeldedaten. Sie baut eine feste npm-Version und setzt den Verschlüsselungsschlüssel als Service-Secret. + +Das grundlegende Setup deckt Flows ab, die APIs verwenden. Hochgeladene Dateien und lokale Vektor-Stores benötigen separaten persistenten Speicher; siehe [Dateispeicher](#file-storage), bevor du diese Funktionen verwendest. + + + +## Voraussetzungen + +- Ein Lizard-Konto mit Zugriff auf App-Hosting und Managed Postgres. +- Node.js, npm und OpenSSL auf deinem Computer. +- Genügend Arbeitsspeicher für deine Flowise-Workload; der Test-Service verwendet 4 GiB. + +Installiere Lizard CLI und schließe die Browser-Anmeldung ab: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + + + +## Das Projekt erstellen + +```bash +mkdir flowise-on-lizard +cd flowise-on-lizard +lizard init --name flowise-on-lizard +lizard add postgres --name flowise-db +lizard add --service flowise +``` + +Verwende `--workspace ` mit `lizard init`, wenn du einen Workspace auswählen musst. Warte, bis die Datenbank läuft. + + + +## Eine feste Flowise-Version bauen + +Erstelle `Dockerfile` mit dem folgenden Inhalt. Dies folgt dem Flowise-Docker-Build und fixiert das npm-Paket auf `3.1.4`: + +```dockerfile +FROM node:24-alpine AS build +RUN apk add --no-cache git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev +ENV PUPPETEER_SKIP_DOWNLOAD=true +RUN npm install -g flowise@3.1.4 --legacy-peer-deps + +FROM node:24-alpine +RUN apk add --no-cache chromium git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev curl +ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser +COPY --from=build /usr/local/lib/node_modules /usr/local/lib/node_modules +COPY --from=build /usr/local/bin /usr/local/bin +RUN chown -R node:node /usr/local/lib/node_modules /usr/local/bin +USER node +EXPOSE 3000 +ENTRYPOINT ["flowise", "start"] +``` + +`--legacy-peer-deps` verhindert die Installation optionaler Peer-Integrationen, einschließlich einer alten nativen SQLite-Abhängigkeit. Dieses Rezept ist auf PostgreSQL und API-basierte Flows ausgelegt; installiere und teste zusätzliche Abhängigkeiten für Nodes, die sie benötigen, separat. + +Wähle die Dockerfile explizit aus: + +```bash +lizard service set flowise --set dockerfilePath=Dockerfile +``` + + + +## PostgreSQL und Verschlüsselung konfigurieren + +Verweise beim Flowise-Service auf die Datenbankvariablen: + +```bash +lizard secrets set \ + DATABASE_TYPE=postgres \ + DATABASE_HOST='${{flowise-db.PGHOST}}' \ + DATABASE_PORT='${{flowise-db.PGPORT}}' \ + DATABASE_USER='${{flowise-db.PGUSER}}' \ + DATABASE_PASSWORD='${{flowise-db.PGPASSWORD}}' \ + DATABASE_NAME='${{flowise-db.PGDATABASE}}' \ + --service flowise +``` + +Behalte die einfachen Anführungszeichen bei, damit deine Shell die Referenzen nicht expandiert. Lizard löst sie auf, wenn der Service startet. + +Erzeuge die folgenden Secrets einmal während der Einrichtung: + +```bash +lizard secrets set \ + FLOWISE_SECRETKEY_OVERWRITE="$(openssl rand -hex 32)" \ + JWT_AUTH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + JWT_REFRESH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + EXPRESS_SESSION_SECRET="$(openssl rand -hex 32)" \ + TOKEN_HASH_SECRET="$(openssl rand -hex 32)" \ + SECURE_COOKIES=true \ + --service flowise +``` + +Bewahre diese Werte sicher auf. Insbesondere `FLOWISE_SECRETKEY_OVERWRITE` muss erhalten bleiben: Flowise benötigt denselben Schlüssel, um bereits in PostgreSQL gespeicherte Anmeldedaten zu entschlüsseln. Erzeuge die Secrets beim Neustart, Redeploy oder Upgrade nicht neu. + + + +## Bereitstellen und dein Konto erstellen + +```bash +lizard up --service flowise --port 3000 +``` + +Der erste Build installiert Flowise und seine Abhängigkeiten, daher kann er mehrere Minuten dauern. Öffne die von der Bereitstellung zurückgegebene HTTPS-URL und erstelle das erste Eigentümerkonto, bevor du die URL weitergibst. Melde dich im Editor an. + +Setze die öffentliche URL für Links, die Flowise erzeugt, und ersetze dabei das Beispiel durch deine tatsächliche HTTPS-URL: + +```bash +lizard secrets set APP_URL=https://YOUR-SERVICE.onlizard.com --service flowise +``` + +Diese Änderung startet den Service neu. Konfiguriere SMTP separat, wenn du E-Mails zum Zurücksetzen von Passwörtern oder Einladungen benötigst. + + + +## Persistenz prüfen + +Erstelle und speichere einen Flow. Füge eine Test-Anmeldedatenkonfiguration hinzu und starte dann Flowise neu: + +```bash +lizard restart --service flowise +``` + +Warte, bis der Service läuft, melde dich erneut an und prüfe, dass der Flow und die Anmeldedaten erhalten bleiben. Führe einen Flow aus, der die Anmeldedaten verwendet, um zu bestätigen, dass Flowise sie weiterhin entschlüsseln kann. Wiederhole die Prüfung nach einem Redeploy: + +```bash +lizard redeploy --service flowise +``` + +Erstelle Backups sowohl von PostgreSQL als auch vom Verschlüsselungsschlüssel. Ein Datenbank-Backup ohne den Schlüssel kann gespeicherte Anmeldedaten nicht wiederherstellen. + + + +## Dateispeicher + +PostgreSQL speichert nicht jede Datei, die Flowise schreibt. Dieses Setup bindet kein persistentes Dateivolume ein, daher können lokale Uploads, lokale Vektor-Datenbanken und Datei-Logs verschwinden, wenn der Container ersetzt wird. + +Bevor du Uploads oder Dokument-Workflows verwendest, konfiguriere einen privaten S3-Bucket mit den [Speichervariablen](https://docs.flowiseai.com/configuration/environment-variables) von Flowise. Setze `STORAGE_TYPE=s3`, `S3_STORAGE_BUCKET_NAME`, `S3_STORAGE_ACCESS_KEY_ID`, `S3_STORAGE_SECRET_ACCESS_KEY` und `S3_STORAGE_REGION`. Für einen S3-kompatiblen Anbieter setze außerdem `S3_ENDPOINT_URL` und `S3_FORCE_PATH_STYLE=true`. + +Lizard's Managed Object Storage erstellt einen öffentlich lesbaren `default`-Bucket. Lege keine privaten Flowise-Dokumente in diesem Bucket ab, ohne zuvor dessen Zugriffseinstellung zu ändern. Das PostgreSQL-Setup oben richtet weder Dateispeicher, lokale Vektor-Stores noch Queue-Worker ein oder testet sie. + + + +## Fehlerbehebung und Updates + +```bash +lizard events --service flowise +lizard logs --build --service flowise +lizard logs --service flowise +``` + +Wenn ein erster Bereitstellen ein Timeout erreicht, während das Image noch geladen wird, prüfe `lizard events`. Sobald der Container gestartet wurde, versuche `lizard up --service flowise --port 3000` erneut. Ein Service ohne zuvor erfolgreichen Build kann `lizard redeploy` noch nicht verwenden. + +Für Updates sichere die Datenbank, lies die Release-Hinweise von Flowise, ändere die npm-Version in der Dockerfile und lade sie dann erneut mit `lizard up` hoch. Prüfe die neue Version und führe die Persistenzprüfungen durch, bevor du dich auf das Update verlässt. diff --git a/_locales/de/guides/index.mdx b/_locales/de/guides/index.mdx new file mode 100644 index 0000000..033d9d4 --- /dev/null +++ b/_locales/de/guides/index.mdx @@ -0,0 +1,25 @@ +--- +description: "Anleitungen für Bereitstellungen aus Coding-Agents, das Hosten entfernter MCP-Server, das Ausführen von Telegram-Workern und das Beibehalten von Sandbox-Dateien." +--- + + + +# Anleitungen + +Wähle die Workload aus, die du ausführen möchtest. Jede Anleitung erklärt Einrichtung, Prüfungen und Einschränkungen; verwende die Befehlsreferenz, wenn du die genaue Syntax einer Option brauchst. + +| Aufgabe | Anleitung | +|---|---| +| Eine von Claude Code, Codex oder Cursor geschriebene App deployen | [Aus einem Coding-Agent deployen](/guides/deploy-from-coding-agent) | +| Einem MCP-Client einen entfernten HTTPS-Endpunkt bereitstellen | [Einen entfernten MCP-Server hosten](/guides/deploy-mcp-server) | +| Einen Telegram-Long-Polling-Prozess dauerhaft ausführen | [Einen Telegram-Bot ausführen](/guides/telegram-bot) | +| Warteschlangen-Jobs ohne HTTP-Listener verarbeiten | [Hintergrund-Worker](/deploy/workers) | +| Code in einem separaten Linux-Gast ausführen | [Sandboxes-Schnellstart](/sandboxes/quickstart) | +| Website-Analytics mit PostgreSQL erfassen | [Umami ausführen](/guides/umami) | +| Flowise-Flows und verschlüsselte Zugangsdaten in PostgreSQL beibehalten | [Flowise ausführen](/guides/flowise) | +| Dateien in einer späteren Sandbox wiederverwenden | [Persistent Volumes](/sandboxes/volumes) | + +Prüfe [Limits](/platform/limits), [Speicherung und Wiederherstellung](/platform/storage-and-recovery) und [bekannte Probleme](/platform/known-issues), wenn du eine Ressource auswählst. + +Lies die [Ergebnisse der Szenariotests](/guides/validation) für getestete Versionen, Cloud-Prüfungen und verbleibende Lücken. + diff --git a/_locales/de/guides/telegram-bot.mdx b/_locales/de/guides/telegram-bot.mdx new file mode 100644 index 0000000..c493cb6 --- /dev/null +++ b/_locales/de/guides/telegram-bot.mdx @@ -0,0 +1,101 @@ +--- +description: "Führe einen Telegram Long-Polling-Bot als Lizard Worker aus. Konfiguriere sein Token, deaktiviere HTTP-Routing, behalte eine Replik und prüfe Nachrichten sowie Wiederholungen." +--- + + + +# Einen Telegram-Bot ausführen + +Ein Long-Polling-Bot ist ein Hintergrund-Worker: Er fragt Telegram nach Updates und benötigt keinen öffentlichen HTTP-Endpunkt. Führe ihn mit `containerPort=0` und einer Replik pro Bot-Token aus. + +**Teststatus:** Sieben lokale Tests mit nachgebildeten Telegram-Antworten bestehen. Wir haben diese Anleitung nicht mit einem echten Bot in der Cloud geprüft. Verwende einen separaten Test-Bot und führe die unten stehenden Prüfungen für Nachrichten und Neustarts vollständig durch, bevor du dich darauf verlässt. Siehe [Ergebnisse der Szenario-Tests](/guides/validation). + + + +## Bevor du beginnst + +Erstelle einen Bot mit BotFather und halte sein Token geheim. Du benötigst Python 3.13, Lizard CLI und ein Projekt, das du deployen kannst. Ein Bot mit Long Polling darf keinen aktiven Webhook haben; prüfe seine aktuelle Konfiguration, bevor du änderst, wie er Updates empfängt. + +Die [Beispieldateien](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/telegram-worker) enthalten `worker.py`, ein Dockerfile und lokale Unit-Tests. Die Tests rufen Telegram nicht auf. Der Echo-Handler speichert seinen Offset im Arbeitsspeicher; er ist kein Verarbeitungssystem mit Exactly-once-Garantie. + + + +## Lokal prüfen + +Aus dem Beispielverzeichnis: + +```bash +python3 -m unittest -v +``` + +Die Prüfungen decken Textantworten, ignorierte Updates, leere Polls und fehlgeschlagene Sendevorgänge ab. Führe den Bot lokal mit nur gesetztem `TELEGRAM_BOT_TOKEN` nur dann aus, wenn du Antworten senden willst. Beende diesen lokalen Prozess, bevor du den gehosteten Worker startest. + + + +## Als Worker deployen + +```bash +lizard init --name telegram-bot +lizard add --service bot +``` + +Melde dich mit `lizard login` an, falls ein Befehl meldet, dass eine Authentifizierung erforderlich ist. Setze `TELEGRAM_BOT_TOKEN` vor dem Deployment auf dem **Bot-Service**. Du kannst den Variablen-Editor im Dashboard verwenden oder den Wert in eine lokale Datei `.env` schreiben und importieren: + +```bash +lizard secrets import --service bot < .env +lizard run --service bot -- python3 check_bot.py +lizard up --service bot --port 0 +``` + +Die Vorabprüfung prüft das Token mit `getMe` und lehnt einen Bot mit aktivem Webhook ab. Sie entfernt oder ändert diesen Webhook nicht. Ein zweiter Polling-Prozess kann weiterhin zu Konflikten führen: Beende jede lokale Kopie vor dem Deployment. + +Das Beispiel schließt `.env*` von Uploads aus. Halte das Token aus Quelldateien und Screenshots heraus. Unter macOS mit Lizard CLI 0.3.92 stelle dem Upload-Befehl `COPYFILE_DISABLE=1` voran. Lies das letzte Deployment-Ereignis und die Logs, auch wenn der Befehl erfolgreich beendet wird. + +Für einen bestehenden Service setze den Worker-Modus ausdrücklich: + +```bash +lizard service set bot --set containerPort=0 +``` + +Nachdem du den Worker-Modus bei einem laufenden Service geändert hast, übernimm die Änderung mit `lizard redeploy --service bot`. Prüfe die Deployment-Ereignisse, bevor du einen weiteren Build anforderst. Der Worker-Modus überspringt HTTP-Port-Prüfungen und die Route des Load-Balancers; füge keinen Dummy-Webserver hinzu, nur damit dieser Prozess wie eine HTTP-App aussieht. + + + +## Ergebnis prüfen + +```bash +lizard ps --json +lizard logs --service bot --json +lizard events --json +``` + +Im Log sollte `Telegram worker started` erscheinen. Sende eine Nachricht an deinen Bot und prüfe, dass genau eine Echo-Antwort zurückkommt. Stoppe und starte dann den Worker in einem freigegebenen Testfenster neu und bestätige, dass er sich wieder verbindet. Ein Worker, der als laufend markiert ist, benötigt trotzdem diese Prüfung auf Anwendungsebene. + + + +## Häufige Fehler + +| Symptom | Prüfen | +|---|---| +| Prozess beendet sich sofort | Setze `TELEGRAM_BOT_TOKEN` auf dem Service, der ihn verwendet. | +| HTTP-Health-Check wird nie erfolgreich | Der Worker-Modus muss `containerPort=0` verwenden. | +| Updates stoppen oder es erscheinen Konfliktfehler | Nur ein Polling-Prozess sollte dieses Token verwenden; prüfe auf einen lokalen Prozess, eine weitere Replik oder einen aktiven Webhook. | +| Wiederholte Antworten nach einem Fehler | Die Demo speichert Offsets nicht dauerhaft und dedupliziert Update-IDs nicht. Füge dauerhafte Idempotenz hinzu, bevor du irreversible Aktionen verarbeitest. | +| Häufige Wiederholungen | Prüfe Netzwerkzugriff, Gültigkeit des Tokens, Telegram-Limits und deinen Handler. Gib keine Request-URLs aus: Sie enthalten das Token. | + + + +## Zustand und Kosten + +Für einen dauerhaften Bot-Zustand verbinde [Managed Postgres](/addons/postgres). Speichere verarbeitete Update-IDs und gestalte Handler so, dass Wiederholungen sicher sind. Long Polling kann den Worker auch zwischen Nachrichten aktiv halten; plane das Budget anhand von [pricing](https://lizard.build/pricing) und der beobachteten Ressourcennutzung, nicht allein anhand der Nachrichtenanzahl. + + + +## Verwandte Anleitungen + +- [Hintergrund-Worker](/deploy/workers) +- [Logs](/observability/logs) +- [Limits](/platform/limits) +- [Telegram getUpdates-Referenz](https://core.telegram.org/bots/api#getupdates) + +Siehe [Ergebnisse der Szenario-Tests](/guides/validation) für geprüfte Versionen, Cloud-Ergebnisse und verbleibende Einschränkungen. diff --git a/_locales/de/guides/umami.mdx b/_locales/de/guides/umami.mdx new file mode 100644 index 0000000..6b9d5a6 --- /dev/null +++ b/_locales/de/guides/umami.mdx @@ -0,0 +1,122 @@ +--- +description: "Stelle Umami mit Managed Postgres bereit, setze die Verschlüsselungsgeheimnisse und prüfe die Analytics nach einem Neustart und einer erneuten Bereitstellung." +--- + + + +# Umami ausführen + +Diese Anleitung verwendet das offizielle Umami-Docker-Image auf Lizard mit einer separaten PostgreSQL-Datenbank. Sie nutzt Lizard CLI, um ein kleines lokales Dockerfile bereitzustellen und Umami über HTTPS zu veröffentlichen. + + + +## Voraussetzungen + +- Ein Lizard-Konto mit Zugriff auf App-Hosting und Managed Postgres. +- Node.js und npm auf deinem Computer sowie OpenSSL zum Erzeugen von Geheimnissen. + +Installiere Lizard CLI und melde dich an: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +Schließe die Anmeldung in deinem Browser ab, bevor du fortfährst. Die folgenden Befehle wurden mit Lizard CLI 0.3.95 und Umami 3.3.1 getestet. + + + +## Projekt und Datenbank erstellen + +Verwende für diese Bereitstellung ein neues Verzeichnis: + +```bash +mkdir umami-on-lizard +cd umami-on-lizard +lizard init --name umami-on-lizard +lizard add postgres --name umami-db +lizard add --service umami +``` + +Wenn du zu mehr als einem Workspace gehörst, übergib `--workspace ` an `lizard init`, um einen auszuwählen. Warte, bis die Datenbank `running` erreicht, bevor du Umami bereitstellst. + + + +## Image und Geheimnisse festlegen + +Erstelle eine Datei mit dem Namen `Dockerfile`: + +```dockerfile +FROM ghcr.io/umami-software/umami:3.3.1 +EXPOSE 3000 +``` + +Weise Lizard an, diese Datei unverändert zu verwenden: + +```bash +lizard service set umami --set dockerfilePath=Dockerfile +``` + +Verbinde die Datenbank und erzeuge zwei separate Geheimnisse: + +```bash +lizard secrets set \ + DATABASE_URL='${{umami-db.DATABASE_URL}}' \ + APP_SECRET="$(openssl rand -hex 32)" \ + TWO_FACTOR_ENCRYPTION_KEY="$(openssl rand -hex 32)" \ + --service umami +``` + +Behalte die einfachen Anführungszeichen um die Datenbankreferenz bei: Lizard löst sie beim Start des Dienstes auf. Die Werte gehören zu diesem Dienst, daher erhalten andere Apps im Projekt sie nicht. + +Speichere beide erzeugten Geheimnisse in deinem Passwort-Manager. Setze sie einmal bei der Einrichtung; erzeuge sie nicht neu, wenn du neu startest oder ein Upgrade durchführst. `TWO_FACTOR_ENCRYPTION_KEY` ist für die Zwei-Faktor-Authentifizierung erforderlich. + + + +## Bereitstellen und anmelden + +Führe im Verzeichnis mit dem Dockerfile Folgendes aus: + +```bash +lizard up --service umami --port 3000 +``` + +Das Umami-Image führt beim Start die Einrichtung der Datenbank und die Migrationen aus. Für dieses Image ist kein separater Migrationsbefehl nötig. + +Öffne die von der Bereitstellung zurückgegebene HTTPS-URL. Melde dich bei einer neuen Umami-3.3.1-Datenbank mit dem Benutzernamen `admin` und dem Passwort `umami` an und ändere dann sofort das Passwort in deinem Profil, bevor du die URL weitergibst. Füge eine Website hinzu und installiere ihr Tracking-Skript auf einer Seite, die du kontrollierst. + +Wenn die Bereitstellung fehlschlägt, prüfe ihren Status und die Logs: + +```bash +lizard events --service umami +lizard logs --build --service umami +lizard logs --service umami +``` + +Wenn der erste Start wegen Zeitüberschreitung fehlschlägt, prüfe `lizard events` auf die Bereitschaft des Containers. Sobald der Container gestartet ist, wiederhole den Upload mit `lizard up --service umami --port 3000`. + + + +## Datenpersistenz prüfen + +Besuche die getrackte Seite und bestätige, dass Umami einen Seitenaufruf erfasst. Starte die Anwendung neu: + +```bash +lizard restart --service umami +``` + +Warte, bis der Dienst wieder läuft. Bestätige, dass dein neues Passwort funktioniert und dass die Website und der Seitenaufruf erhalten bleiben. Wiederhole die Prüfung dann nach einer erneuten Bereitstellung: + +```bash +lizard redeploy --service umami +``` + +Umami speichert Konten, Website-Einstellungen und Analytics in PostgreSQL. Die Anwendung benötigt für diese Datensätze kein Dateivolume. Behalte die Datenbank und die Verschlüsselungsgeheimnisse bei, wenn du die App ersetzt oder aktualisierst. Eine Neustartprüfung ersetzt keinen getesteten Plan für Datenbank-Backup und -Wiederherstellung. + + + +## Umami aktualisieren + +Erstelle vor dem Upgrade ein Backup von PostgreSQL und lies die Release Hinweise. Ändere das Image-Tag im lokalen Dockerfile und führe dann `lizard up --service umami --port 3000` erneut aus. Bei diesem Upload-basierten Setup erstellt `lizard redeploy` die zuletzt hochgeladenen Dateien neu; lokale Änderungen werden nicht hochgeladen. + +Siehe [PostgreSQL-Anleitung von Lizard](https://lizard.build/docs/addons/postgres/) für den Datenbankzugriff und [Speicher und Wiederherstellung](https://lizard.build/docs/platform/storage-and-recovery/) für die Backup-Planung. diff --git a/_locales/de/guides/validation.mdx b/_locales/de/guides/validation.mdx new file mode 100644 index 0000000..5733c0f --- /dev/null +++ b/_locales/de/guides/validation.mdx @@ -0,0 +1,39 @@ +--- +description: "Prüft die Anleitungen für MCP, Coding-Agent, Redis-Worker und Telegram: Cloud-Ergebnisse, Neustartverhalten, getestete Versionen und verbleibende Einschränkungen." +--- + + + +# Testergebnisse der Szenario-Anleitungen + +Am 2026-09-07 haben wir diese Anleitungen in einem separaten Testprojekt mit Lizard CLI 0.3.92 geprüft. Anwendungsprüfungen sind vom Build-Status getrennt. Die Tests verwendeten die Befehle aus den Anleitungen, mit einem eigenen Projektnamen und dem Dokumentations-Test-Branch für das GitHub-Beispiel. + +| Anleitung | Ergebnis | Prüfungen | +|---|---|---| +| [Remote MCP](/guides/deploy-mcp-server) | Lokal und in der Cloud bestanden | Health 200; fehlendes und ungültiges Token 401; authentifiziertes GET 405; abgelehnter Origin 403; initialize, tools/list und tools/call; Ergebnis `5` über öffentliches HTTPS | +| [Coding-Agent: Upload](/guides/deploy-from-coding-agent) | Bestanden | `lizard up`, Health 200, datenbankgestützte Antwort 200, unbekannte Route 404; eine aktualisierte Postgres-Zeile blieb nach einem Service-Neustart erhalten | +| [Coding-Agent: GitHub](/guides/deploy-from-coding-agent) | Bestanden | Repository mit `--no-deploy` verknüpft; Branch, Stammverzeichnis und Umgebung vor `redeploy` konfiguriert; die öffentliche App las dieselbe vorhandene Postgres-Zeile | +| [Redis worker](/deploy/workers) | Bestanden | Port 0; enqueue und Ergebnis; Ergebnis nach Neustart beibehalten; neuer Job nach Neustart; ein nicht abgeschlossener Verarbeitungseintrag wurde beim Start wiederhergestellt | +| [Telegram bot](/guides/telegram-bot) | Nur lokale Tests | Sieben gemockte Tests decken Updates, fehlgeschlagene Sends, Token-Prüfungen und Webhook-Ablehnung ab. Ein echter Token-, Chat- und Cloud-Echo-Test ist weiterhin erforderlich | + + + +## Versionen + +Der MCP-Container lief mit Node.js 22.23.2 und MCP TypeScript SDK 1.30.0. Das coding-agent-Beispiel verwendet `pg` 8.16.3 und war mit Managed Postgres verbunden, auf dem PostgreSQL 18.4 lief. Der Worker-Container lief mit Python 3.13.15 und redis-py 6.4.0. Lockfiles für Abhängigkeiten oder exakte Requirements liegen bei den Beispielen. + + + +## Umfang + +Die MCP-Prüfung deckt den zustandslosen HTTP-Transport des Beispiels und ein festes Bearer-Token ab. Sie stellt keine OAuth-Kompatibilität, Browser-Unterstützung, Streaming über lange Zeiträume oder Lastkapazität fest. Das Token läuft nach einer Stunde ab. + +Die GitHub-Prüfung verwendete den Dokumentations-Branch und das Verzeichnis `_examples/agent-app`. Sie testete ein explizites Redeploy; nicht getestet wurden jede Berechtigungskonfiguration für private Repositories oder jedes Webhook-Ereignis. + +Die Redis-Wiederherstellungsprüfung legte vor dem Neustart eines einzelnen Consumers einen nicht abgeschlossenen Verarbeitungseintrag an. Nicht getestet wurden Redis-Ausfall, mehrere Worker oder genau-einmalige externe Effekte. Die Datenbankprüfung belegt Persistenz über einen Anwendungsneustart hinweg, nicht Backup oder Disaster Recovery. + +Die Laufzeit-Log-Tails waren für die Test-Services anfangs leer. Ein Live-Log-Stream des Workers lieferte später einen neu verarbeiteten Job. Verwende die HTTP-, MCP-Client- und Job-Ergebnis-Prüfungen als Abschlusskriterien; ein leerer Log-Tail allein belegt weder Erfolg noch Misserfolg. + +Das Telegram-Beispiel ist nicht als cloud-verifiziert markiert. Sein Preflight liest `getMe` und `getWebhookInfo`, ohne den Webhook des Bots zu ändern. Verwende einen separaten Test-Bot, bevor du seine Polling-Schleife aktivierst. + +Siehe [Framework-Testergebnisse](/framework-guides/validation) für den separaten Framework-Batch mit 16 Rezepten und [known issues](/platform/known-issues) für CLI-Archiv- und Exit-Code-Einschränkungen bei fehlgeschlagenen Builds. diff --git a/_locales/de/index.mdx b/_locales/de/index.mdx new file mode 100644 index 0000000..4120d7c --- /dev/null +++ b/_locales/de/index.mdx @@ -0,0 +1,57 @@ +--- +description: "Stellen Sie eine App bereit, führen Sie einen Worker aus, verbinden Sie Managed Postgres oder führen Sie Code in Sandboxes aus. Wählen Sie eine Aufgabe, folgen Sie einer Anleitung und prüfen Sie die Limits." +--- + + + +# Lizard-Dokumentation + +Lizard erstellt und betreibt Anwendungen aus einem GitHub-Repository oder einem lokalen Ordner. Verwenden Sie Lizard CLI oder das Dashboard, um einen Webservice bereitzustellen, einen Hintergrund-Worker auszuführen, Managed Postgres oder Managed Redis zu verbinden und Logs zu prüfen. Verwenden Sie Lizard SDK, um Sandboxes für die Codeausführung zu erstellen. + + + +## Aufgabe auswählen + +| Ich möchte… | Hier starten | +|---|---| +| Meine erste App bereitstellen | [App-Schnellstart](/getting-started) | +| Next.js, React, Vue oder eine Python-App bereitstellen | [Framework-Anleitungen](/framework-guides) | +| Über Claude Code oder einen anderen Coding-Agenten bereitstellen | [Anleitung für Coding-Agenten](/guides/deploy-from-coding-agent) | +| Einen Remote-MCP-Server hosten | [Remote-MCP-Anleitung](/guides/deploy-mcp-server) | +| Einen Telegram-Bot dauerhaft ausführen | [Telegram-Worker-Anleitung](/guides/telegram-bot) | +| Eine Datenbank verbinden | [Managed Postgres](/addons/postgres) | +| Generierten Code in einer separaten Umgebung ausführen | [Sandboxes-Schnellstart](/sandboxes/quickstart) | +| Dateien nach dem Ende einer Sandbox behalten | [Persistent Volumes](/sandboxes/volumes) | + + + +## Eine App bereitstellen + +Installieren Sie Lizard CLI und melden Sie sich an. Stellen Sie dann ein Repository bereit, auf das Sie zugreifen können: + +```bash +npm install -g @lizard-build/cli +lizard login +lizard add -r your-org/your-app +``` + +Lizard erstellt das Image auf seinen Servern, daher ist auf diesem Weg kein lokales Docker erforderlich. [lizardpack](/concepts/build-pipeline) erkennt unterstützte Projekte; Projekte mit speziellen Build-Anforderungen können explizite Befehle oder ein Dockerfile verwenden. Prüfen Sie die Build-Logs und verifizieren Sie nach der Bereitstellung die URL der Anwendung. + + + +## Ihre Ressourcen verstehen + +Ein **Workspace** gruppiert Mitglieder und Projekte. Ein **Projekt** gruppiert Services, Datenbanken und Sandboxes. Ein **Service** führt eine Anwendung oder einen Worker aus. Managed Postgres, Managed Redis und Managed Object Storage stellen Datendienste bereit, mit denen sich Anwendungen über Umgebungsreferenzen verbinden. + +Für Apps und Sandboxes gelten unterschiedliche Regeln für Laufzeit und Speicher. Lesen Sie [Limits](/platform/limits) und [Speicher und Wiederherstellung](/platform/storage-and-recovery), bevor Sie sich auf Größe, Lebensdauer oder Datenaufbewahrung einer Ressource verlassen. + + + +## Die passende Detailtiefe finden + +- [Anleitungen](/guides) behandeln eine Aufgabe von der Einrichtung bis zur Prüfung des Ergebnisses. +- [Framework-Anleitungen](/framework-guides) enthalten Build-Befehle, Adapter, Ports und Prüfungen für jeden Stack. +- [Kernkonzepte](/concepts/architecture) erklären Projekte, Builds und Bereitstellungen. +- [Lizard CLI-Referenz](/cli) listet Befehle, Flags und Exit-Codes auf. +- [Fehlerbehebung](/deploy/troubleshooting/service-never-healthy) hilft dabei, einen fehlgeschlagenen Start zu diagnostizieren. +- [Bekannte Probleme](/platform/known-issues) dokumentiert Limits und Wiederherstellungsfälle, die Sie vor einem Release prüfen sollten. diff --git a/_locales/de/manifest.json b/_locales/de/manifest.json new file mode 100644 index 0000000..6011f83 --- /dev/null +++ b/_locales/de/manifest.json @@ -0,0 +1,576 @@ +{ + "locale": "de", + "status": "published", + "pages": [ + { + "path": "addons/index.mdx", + "sourceSha256": "a364ec2783f0102fb3067cc844c4db4e6709b3bc522508dea3ccc67aae830ae0", + "translationSha256": "44e7d2421f54460726c6838dfaee65bca7b45bccd88caa4e0d045d73b10893dc", + "status": "published" + }, + { + "path": "addons/postgres.mdx", + "sourceSha256": "78346399743959929c09c87d1d98a7e8274d93c1e21a764df94a02b613ac0d09", + "translationSha256": "e291e099a2d6cde1432bc05c6e7e472fb70ae42ff0393627bbb47a5318397ca1", + "status": "published" + }, + { + "path": "addons/redis.mdx", + "sourceSha256": "5c295a88f06837b2c581b62b2a8787dec1f8da73c77cdf1c8a8b051d5fdd9c19", + "translationSha256": "baed9fdbf19dba68610f2c1fac0adb4c9ef1185a753d24629b2946d17532675e", + "status": "published" + }, + { + "path": "addons/storage.mdx", + "sourceSha256": "60eb80b5a079fc37daa87d064bbb6824ff8061682f54671567389b41ea9a2e3a", + "translationSha256": "4a5875633d24be826505df8c11235136ac20737bed5987de129b76901c9814de", + "status": "published" + }, + { + "path": "agents.mdx", + "sourceSha256": "6d12cad052e608f5685ce8a08051d0b5c9d0f0981c06ddf7aa422479f8a6a20a", + "translationSha256": "5906bf6023b4d10c837e69d1477d2fed8785d3e180e0633ab007f781e075c700", + "status": "published" + }, + { + "path": "cli/add.mdx", + "sourceSha256": "da07da89b28ff85a02dd9afd621d75c935a8e47e26c3bb1bebdeb4fae7d935b7", + "translationSha256": "a8b806751c657d2f5f308cf215781849a9949317a4991f7795dffe3d8292cfd3", + "status": "published" + }, + { + "path": "cli/config.mdx", + "sourceSha256": "7ff4c3a6d511e1bf7086f6ea11f47af473c9fd6d15865808bdd0548c265bcd56", + "translationSha256": "81c7b68d29e3d923c719dc0b287f24d050e18eb1e651fa88e2519c246af871f8", + "status": "published" + }, + { + "path": "cli/docs.mdx", + "sourceSha256": "2f99ebda3a4339d975e1b12c6e8949b4aac33e2b6b4284cfbf5944b274936b83", + "translationSha256": "d8cab399cae3bd583bb2a5d8d46dad47d8e10b36cccf5ab2e7112e32aafcf1b8", + "status": "published" + }, + { + "path": "cli/domain.mdx", + "sourceSha256": "9d4d1e70a6b4078de6486abf9f3f8c679b922e117823232d41df0e403918458f", + "translationSha256": "672d9288139b7a0b927769dd8fa730e7d32238d10866f44c56855168859dff45", + "status": "published" + }, + { + "path": "cli/events.mdx", + "sourceSha256": "ce890a024e8b37c7566a3f23d74fe867554aacbcf034103a64d48ba910b4aa4d", + "translationSha256": "984900f7875e9fe324536d43ca3789bee1c6434d19ff925d8a5d980751036474", + "status": "published" + }, + { + "path": "cli/git.mdx", + "sourceSha256": "d41bde854400c6879516d11f06a0792adad0491f294addcb6a3fbbaca140d2f5", + "translationSha256": "b66d21943cc72776f9e253f2d298f0ac4631ba2a51695b03035c9d704aeb2dc5", + "status": "published" + }, + { + "path": "cli/index.mdx", + "sourceSha256": "b9f5bb24b661770d8b5fe2916ea43890af08cafc17f32ccd0e49d2e56a0df422", + "translationSha256": "6b8787cd9e340bebb25ec1c603b32f394e2d6a214d95d72ab94b8ab24cc129c2", + "status": "published" + }, + { + "path": "cli/init.mdx", + "sourceSha256": "9ea4e3b5641acc86a3bb0e7013f74cd03df18d64a150858f33cc4220e987cfc7", + "translationSha256": "3c335d2fa6718bfcbc1edfd57639d436132dfae0ce2f14775d108a90e13edd0e", + "status": "published" + }, + { + "path": "cli/json.mdx", + "sourceSha256": "0db2f5c74b3d7d55b467f5235d38805f5ba531b3b56b60eeb591722b89634798", + "translationSha256": "e3fea8ebdedcb18e348dafcbbd3a05f2c4d43a7a619132709e52a7b4ee2bca03", + "status": "published" + }, + { + "path": "cli/link.mdx", + "sourceSha256": "c830b5269697edcce4a1344de712a26319d60dbb73f9aee71f905da45f301c90", + "translationSha256": "f56e990aa851cdf32b4a9117aafaef3c0bd19b5ba49529c9a32ae3069f23238e", + "status": "published" + }, + { + "path": "cli/login.mdx", + "sourceSha256": "732fd0d32942e45da0f61325478ac2853710161f8d8dd9cbd874b192ddd41220", + "translationSha256": "9c50cfd0d9cdec16809effcaf1a95cd35719907b34b77932c1036bfd029e60b9", + "status": "published" + }, + { + "path": "cli/logout.mdx", + "sourceSha256": "a8e49ead7c934a4c29d44421349bd46d3f7f1cc81dbde03ef4350d10cbf12e03", + "translationSha256": "0d70b27d0bcae0b3821a502486166e8b795d514699511f137cb31fa8018ba299", + "status": "published" + }, + { + "path": "cli/logs.mdx", + "sourceSha256": "deebb5f030fb9b3a36000036f9b8f829fc8319cd0c559ebe0f528f175d5eb384", + "translationSha256": "3530dc06f30a2e27e46fe52d5116ca48e6b31c815ab84054ef84b576b8df7124", + "status": "published" + }, + { + "path": "cli/metrics.mdx", + "sourceSha256": "dcfa3c003c126ccbc276d2423d5d8fab30adfb685459c4cf546cc53ed02d3429", + "translationSha256": "dff9c866f45dd0c97e552c6890072ee3bbe0619087bde0c983b57e9236adee9f", + "status": "published" + }, + { + "path": "cli/open.mdx", + "sourceSha256": "34659aaba345efeca309eded62ca791414e7f2cac10aa6a66b1fc81a6adcc7cd", + "translationSha256": "4f55e44cde8fc478cc22ec3651f836ee24b9113ffdfe778a68c09286f03c9ad6", + "status": "published" + }, + { + "path": "cli/port.mdx", + "sourceSha256": "925f588fe174b968738163a0c064af2090b9d4489dd82a75a5b111d8c002f8e8", + "translationSha256": "3d32e49e0a9cdf6db3259f946c1f08689d7c95af78ecd184fae840b1cc860075", + "status": "published" + }, + { + "path": "cli/project.mdx", + "sourceSha256": "3cd89738f9965ece2a6ec8158963cfe3d0f118bf81334dde58792ac858890521", + "translationSha256": "d5f3658205f3921cb551be034d0b2f1ad560bfe121850648d4ed1417727c0f2e", + "status": "published" + }, + { + "path": "cli/ps.mdx", + "sourceSha256": "7cae9f4efdd03bd9cc38affa13ce3537d8f6a6cb8ec4a3e12748235a29afb7d1", + "translationSha256": "9695e0b71ddf11810686dac3364eea24ca6267423533c9cff91150238a0e7377", + "status": "published" + }, + { + "path": "cli/redeploy.mdx", + "sourceSha256": "69e3567d19d1eee5ecb88848519c871170982cd8bdae0cc832848425c00976f4", + "translationSha256": "ed2a27bb2330251ca99ad5bc355d415a30aa89a450e37df1e7fda2e363e1b151", + "status": "published" + }, + { + "path": "cli/regions.mdx", + "sourceSha256": "fb4374ff44f0cb307cda3b11a32d2af140628aecefcc72648c8bd4fac79a0390", + "translationSha256": "69037ae1bfb260f31a06e28cef800bbb962144cfd1e1998ed06d86b613ab4ada", + "status": "published" + }, + { + "path": "cli/restart.mdx", + "sourceSha256": "0001cc039c216e29704bc8dd032843f33eeda479e3b936864c55ebb82c19392b", + "translationSha256": "77449e3d7a68782edd605763a8a8317de6c87ef8a4fe070473e3551c41fe53de", + "status": "published" + }, + { + "path": "cli/run.mdx", + "sourceSha256": "3edbc8067d4e4223e7f8fabab0d031173b096b641134895988c9693bdc10b5d6", + "translationSha256": "a77b92588749a33a0e122660ac623e13ac2a276a5d0895726ed15567444b3414", + "status": "published" + }, + { + "path": "cli/scale.mdx", + "sourceSha256": "d0128acc8893d2b40bc7b663fe48867ed247851cddc52817ef2f1a55a97bef5e", + "translationSha256": "9efa037427345bd83de5b338c92f549ebbca51701408ed85eb8f9b8683dcf6a6", + "status": "published" + }, + { + "path": "cli/secrets.mdx", + "sourceSha256": "635491af6079e6a4f8c718f5443f5b19b9b3e8697957a2917a451631eecf3282", + "translationSha256": "4a4c5841fbc29eae90e029be02ac53a33b95652169f3f5cde8822df21502dfa3", + "status": "published" + }, + { + "path": "cli/service.mdx", + "sourceSha256": "f4a4dedae24ae7928cc0e8279525f80551f1bb01b209beb97254b5966d8ff038", + "translationSha256": "f5e5c174e1d1e894e5bdb58c34da9fce622ca141bd6f84514ec9ef09aa352512", + "status": "published" + }, + { + "path": "cli/skills.mdx", + "sourceSha256": "5ee058f81c64343d5667de9ebd49f1bc975010a25258a74ce92458d638b7731b", + "translationSha256": "57ad7fbba1516398626e98007b86776a122490278e34803952e433b746370df0", + "status": "published" + }, + { + "path": "cli/ssh.mdx", + "sourceSha256": "f2c1105cca6be5eff87de0249a23d52dd4b5302065b6a0839ba3106669664e46", + "translationSha256": "d2d83e6abbd45812bffb17c1bd080ef566ecff65371ff04cfcb752c874ac8317", + "status": "published" + }, + { + "path": "cli/status.mdx", + "sourceSha256": "d1c2b6873e7679bdb11253c71aa03566f64c9d46f30a9de283ac58b42a47af8a", + "translationSha256": "98b3976d21085aec898f9668c96479327f8921e59e641acea94e9e66f929481f", + "status": "published" + }, + { + "path": "cli/unlink.mdx", + "sourceSha256": "e824c1f057db0696eee4b37488cdd43292dbe9d08770112d3e9af9b9ab70a5d6", + "translationSha256": "dacb38971292bddc5bcedffdaf69eaf157925ccfc169a8349f1ff6cfd46df536", + "status": "published" + }, + { + "path": "cli/up.mdx", + "sourceSha256": "8d7512c5e26dbf5a0316437f99e1cc93ce0ebdfe7bf69491636ed767eda36695", + "translationSha256": "2b590db021ffd8568c210c369daace003b07924877b240049c8f1b7ba627f3fc", + "status": "published" + }, + { + "path": "cli/upgrade.mdx", + "sourceSha256": "1f33d0a46185278e2858d89f7a19e9e57a63d5dd6bd36c66c0f4f348384c8e93", + "translationSha256": "01852308b431e0fb70e5db0442d9000b70a33822f0b46091328f5ccae7dae41a", + "status": "published" + }, + { + "path": "cli/whoami.mdx", + "sourceSha256": "053bc71c8bd276882bdd10cd64d42ce8e13e500c01424fcfd8e1fd7083b3467d", + "translationSha256": "4acda3b7b9c209c5ca9c802f4125b451bd399cdd8e8289af4026a7f8e95c8909", + "status": "published" + }, + { + "path": "cli/workspace.mdx", + "sourceSha256": "bc138c7663e0b4c8ae76c3b2d55c9f72d83fa08fc19f3475d5e7bc08e7da78d2", + "translationSha256": "1dfcc33e715a59f1108b0a1728d9a5d39475bfb79f1eff30e27729cdecb287fd", + "status": "published" + }, + { + "path": "concepts/architecture.mdx", + "sourceSha256": "fa5a5aa8a4f23b1d89be99fd3d8db0a9f19831991f9d5fb55730fd12dd399cff", + "translationSha256": "ce3b0a5a263292fc398673dfccd96b984fea7b386a9ad19b9f4cb988042f6ed0", + "status": "published" + }, + { + "path": "concepts/build-pipeline.mdx", + "sourceSha256": "b0ec0991712b3f5ef246a1ec3dea10687a7c592debecec517b6498db2daa4bb3", + "translationSha256": "2d1d0d2483e1614c2ba8460a2c77eb613807034d26733b17c2fb4c3ad665be38", + "status": "published" + }, + { + "path": "concepts/deployments.mdx", + "sourceSha256": "0f54a580f17b7c807cadebe8b0d6ef9bfd793e8b16486c51c6cffb40a8eb8bba", + "translationSha256": "8f969550ccc71bde4cada0acd60f3e51b1b2573c58b623ef86ce64a94c5ba0a9", + "status": "published" + }, + { + "path": "concepts/index.mdx", + "sourceSha256": "92ffb749631fb660c542e40ff875f7cd8aa4849c9d77d06f4ac286578ee58bc4", + "translationSha256": "d46819b930b65a14ab1622849e11f33155c1ba498733c7d84db530f4a4f45746", + "status": "published" + }, + { + "path": "dashboard.mdx", + "sourceSha256": "4fa1240afec8962e3df1c9e564280c83963761f2f64b47502eb8b0d9e9d2ed0c", + "translationSha256": "051272d46e3993988d860f25f3e55acae641cf73c6a987b4d7b6298492f4c11f", + "status": "published" + }, + { + "path": "deploy/github.mdx", + "sourceSha256": "697a33210ef14bb34a5074f44847fa69cb7ea169494942fc571e773b200b44c2", + "translationSha256": "faf576cf87d3b9119ad8b67f2e2a3eb72c23b5780b3b5deac9d8b85c3c74c759", + "status": "published" + }, + { + "path": "deploy/index.mdx", + "sourceSha256": "39a4a222ec6cbf55b0d98393646ad7690433e651cc81e3954e85a713157c193f", + "translationSha256": "67276671b82b8208fabcb934c7b19de3b8c85cca0e7d86b464954fa461cbc06a", + "status": "published" + }, + { + "path": "deploy/regions.mdx", + "sourceSha256": "83fc01f4cafa29b368b5bee232de3db69a7fa0c92fd74a6a16381c327005881e", + "translationSha256": "a65ba69b9bcb1eb7595c17a3e8a3738b4115a3ece375312edd5e77d0dcde1c62", + "status": "published" + }, + { + "path": "deploy/scaling.mdx", + "sourceSha256": "563e23a94dc6dd4c634c141f4e953dfc97fcc9a2002cf54ba1030e36e3d83748", + "translationSha256": "d8c369845b96c338433c66d18bf3df035eaa02fec955b21a577d6d09fadf6b00", + "status": "published" + }, + { + "path": "deploy/troubleshooting/double-build.mdx", + "sourceSha256": "1d2254daad7f87e1fbe9e869bd6e0a2f7afbb71ef73e9964e2d2be3b7c011884", + "translationSha256": "b1b92cea993fc0295b61c3a8a982da388cd925a6302dd17f84e67eb118d3525b", + "status": "published" + }, + { + "path": "deploy/troubleshooting/incomplete-dockerfile.mdx", + "sourceSha256": "6f9a46f14284e8c095ef4450973b21b6841073c0b8a959e233e267ff437cc6e0", + "translationSha256": "03cb36eb29607b5e57842e1ab6b209552ae303774ee734e41879e0286186359c", + "status": "published" + }, + { + "path": "deploy/troubleshooting/service-never-healthy.mdx", + "sourceSha256": "9d348e4d46599ed785b0c8d7d906d3672c8ad834114a3d80834467af954e17a8", + "translationSha256": "3d00465f4a864d05ee8bdb19c771c2813df387ee04708dc7dd49b11d36937110", + "status": "published" + }, + { + "path": "deploy/upload.mdx", + "sourceSha256": "17fc2068ae350b3a6ab7349e29fc908abb1ca8087260c7ed8e0025ec5a053941", + "translationSha256": "32af03ab42a89a652a30a364139f01b0b6bea9d676943ba738ce7a8f8562b759", + "status": "published" + }, + { + "path": "deploy/workers.mdx", + "sourceSha256": "43a2bbbb43fb079d035d5cf785f7e6c0536f84ed941e54bc8382a067df0b6fad", + "translationSha256": "7bc28fe5f91e59c68e9d97534e59c5881f7351dffaa200e28fff3049c61aa5c8", + "status": "published" + }, + { + "path": "framework-guides/astro.mdx", + "sourceSha256": "4b89ac3379be48f204f3b932680f0900161e7373ed2436590be3456dd07e6315", + "translationSha256": "97ee493c3344864a5c0481bc9ca80c29c362e7fa995ed6f5888954ce82a19038", + "status": "published" + }, + { + "path": "framework-guides/django.mdx", + "sourceSha256": "11422a3685e71d7b95f2055799ca16c9037ebe8a279c1d9c1c891a2dade79440", + "translationSha256": "d9f030a05f28ccd9f1d2d9681e30091b2fc7d272897dfa87985b30c8e29f4026", + "status": "published" + }, + { + "path": "framework-guides/docusaurus.mdx", + "sourceSha256": "65a0cbde6b2ba696cfb9cc99b45a0c4f7d7d82b24763d82230ede29eb48fe20f", + "translationSha256": "92f2204b2fe8020c76568e210917374a139cdff8ab29717c35c838196e8169cf", + "status": "published" + }, + { + "path": "framework-guides/fastapi.mdx", + "sourceSha256": "9da90747b275c5d3b46aa6827ff7603ec6efb1cc4fffe48836c58d4770f904f8", + "translationSha256": "69848a95f263d310c096ec5b34076a40d28afa8f9a13ff096301bc8c1ab83155", + "status": "published" + }, + { + "path": "framework-guides/hugo.mdx", + "sourceSha256": "c552b74cc22994ab2e17d5a0c1eb4afdaf2d00f64960d9581bcf46300f6c202c", + "translationSha256": "fab7d71d874e088726167dc8a66cb6cd30651e739d19ef5a6576020bef469314", + "status": "published" + }, + { + "path": "framework-guides/index.mdx", + "sourceSha256": "ca924027746d3390d618495318c3fdde147d705193b3e04d30d71ac779c2a33a", + "translationSha256": "f20a5bc159288deadcc0c2ac9253747c08858de16ed16ca08ac22af2e0227c95", + "status": "published" + }, + { + "path": "framework-guides/nextjs/index.mdx", + "sourceSha256": "a30666d082660a9a10e0f8a990b0ac1a476ad16d71c45c3e33d11e8d7f9ed926", + "translationSha256": "b1f3222369adac2e56c6b5a8e2a53005ba50270c02d4a8cdf44f4c23b0bdeae8", + "status": "published" + }, + { + "path": "framework-guides/nextjs/static-export.mdx", + "sourceSha256": "344b7b0a3c925f9e5f7df53054d3aa1525dd8e0b2c98c2e86fd990fa8309a795", + "translationSha256": "164814d6d707ee8ea473a553afd774e6c7aebd6a9f40e843f53217ada68cebf4", + "status": "published" + }, + { + "path": "framework-guides/nuxt.mdx", + "sourceSha256": "edfe7100de75c167475248a291fbb276ab899e4e9aba4aabb37745720b4180ee", + "translationSha256": "60125cfd41e52b883124eebe82698f787303621a492cb72a8ad4e7abdd7b2458", + "status": "published" + }, + { + "path": "framework-guides/react.mdx", + "sourceSha256": "c96a03f9b274d91751231de136d1a37a2554ebcdad8ebffd5b11067c06537c34", + "translationSha256": "7201def0c935f3bd57d0b3229493a44c08f7f90f1ce8c59225a30d47cbfb4273", + "status": "published" + }, + { + "path": "framework-guides/static-routing.mdx", + "sourceSha256": "277dbfc3d581d2ba332fe183807134aca7084876648a0aca7cb4b7cf227caf43", + "translationSha256": "753f9513ed11482778a88ddb1004ffa02dd3b464f1d2759b6d40586e8c6317e3", + "status": "published" + }, + { + "path": "framework-guides/sveltekit.mdx", + "sourceSha256": "eb98e0ae2bcc536998735b23d6d28ea658fce42e1139c78d3eb4570a54347d52", + "translationSha256": "9269750736fe9fbda31a463dd6e9552004ea92669acdd8d224eef35c40669b3a", + "status": "published" + }, + { + "path": "framework-guides/validation.mdx", + "sourceSha256": "068375b554451b4be0aa21b2ea7d53789e61e44cd592947877cce6223240f26f", + "translationSha256": "548f92d1c09c6d21a9603797753b5f6476054ed7bab84d95f7bd63e3c9e6ee15", + "status": "published" + }, + { + "path": "framework-guides/vitepress.mdx", + "sourceSha256": "5e3d98d5d3e2dcbb5af644fb500e39389e216efe772eda2933aa291384aebda4", + "translationSha256": "0a760bbc03473a8148c386f1d4048bfc92c57b68d7b0449ebe4a4ecab5cdb423", + "status": "published" + }, + { + "path": "framework-guides/vue.mdx", + "sourceSha256": "442bd3f20789c9c6243ed364d8e4c350efebeb33a289334ee5222c9047217098", + "translationSha256": "caf96619e51d8a327f2f7284d282ad2bd79db8abe5337aad9bca9cf13be1a7e9", + "status": "published" + }, + { + "path": "getting-started.mdx", + "sourceSha256": "34aa52cecefcc9a9ef34f3eb6586c8cd42de7cad388916e983aabc31c77a1527", + "translationSha256": "bdbd31789ca787fc29a2ca1246021bbabae854b0951f4f9c971c82ed819f2049", + "status": "published" + }, + { + "path": "guides/deploy-from-coding-agent.mdx", + "sourceSha256": "446afe16553138fce16e5ee5aba6c52f600eb9d7f3b326f8822eabbec56ea734", + "translationSha256": "7cfcd473ada9108c6093a892e91bcae3c5652f0e2b29e3518cc1c247744ed303", + "status": "published" + }, + { + "path": "guides/deploy-mcp-server.mdx", + "sourceSha256": "55f7aea7cf3929bb84cd7ad4b67c1feb52cc707d888ec00fa2a7fe702d417738", + "translationSha256": "a30b112dfa9a4ac4d5149ab22b6f87e37e0a686fcd5bc2d463591ee17bb4ceb5", + "status": "published" + }, + { + "path": "guides/flowise.mdx", + "sourceSha256": "fa697aec8657e3ea920d1c88a6095ff442064a0ab3c0a812f10e5e5c5c1ee1b6", + "translationSha256": "840fc8158176ff5a359b3ed5568b0aa5cc815fb48c49dd9744845c855afff10c", + "status": "published" + }, + { + "path": "guides/index.mdx", + "sourceSha256": "6492dcbd87273f0bc2148b1b3cf3e787ce4873932c2b270d11685f8984615ac6", + "translationSha256": "5e8653a81a66979c5545b5401ae28cf6e4be4e0e2e3c5519391cb6261d036062", + "status": "published" + }, + { + "path": "guides/telegram-bot.mdx", + "sourceSha256": "db7b0a93dbae68b767e93022e99d2684dc7f8881bb4060cc2743c2f95742510a", + "translationSha256": "43951db61c741dc66e0f17c5cfbb7c07fdd28359d06822131878a2e570bdf4a5", + "status": "published" + }, + { + "path": "guides/umami.mdx", + "sourceSha256": "60ac58aa3f74b7b22f7a29c2dabb1040983ffb9635ec0364bea5f4eeb9a1a184", + "translationSha256": "ea5a10182a872bbc3b9e7dd44944aca6cef5f37f6cbf9a0df0d4497488bb30f9", + "status": "published" + }, + { + "path": "guides/validation.mdx", + "sourceSha256": "f060ee682789b323ce18e0f282ba6bb47a85accc912583a7600e69546dd9aeed", + "translationSha256": "b7705358083fade68f66a4bf09c160b77629252e7a7b1b249764e2cad84cd86b", + "status": "published" + }, + { + "path": "index.mdx", + "sourceSha256": "45b40d974470539641750f9473f39a6af74fbf999f39e8fb924c867abcc18370", + "translationSha256": "0bc2db151f6161f020d05d19b8a87489b4830ce5b0d4cc77b2c1cbab7fd44b89", + "status": "published" + }, + { + "path": "networking.mdx", + "sourceSha256": "cf23c1a1df8c7e4b7835590d38786dc0574de771374c42dea5c1f5fdfc0079fd", + "translationSha256": "b60d55b76e04d1f4312f25680c7abb2cbb34b107dc6b01f6f158874c8eb5ecd3", + "status": "published" + }, + { + "path": "observability/events.mdx", + "sourceSha256": "db2092362e0139e9ef1b6816eafd3f90ecfca59faad01fe1dfe0383057ce6bdb", + "translationSha256": "1be06cc7da43e41457a177ac6acbcef17b8f45988a9f4644a916f1bd3153f62d", + "status": "published" + }, + { + "path": "observability/index.mdx", + "sourceSha256": "c99b35a322a98276ae9759c2443b7e1ebb77bb2a07b15391d6eff2d4e0d59fd1", + "translationSha256": "63df275d220bb59ba43d767efbbfa8540bec44629ae9680014ebfbde02f3ee5b", + "status": "published" + }, + { + "path": "observability/logs.mdx", + "sourceSha256": "9e1e57fcde78990342ebd7619a1d5762f15dfb35c95142885f8c561bb9e35d40", + "translationSha256": "11609dc08f990e6d0180b0d95651acfe21c9495015b3e92e1adc262d8d13597e", + "status": "published" + }, + { + "path": "observability/metrics.mdx", + "sourceSha256": "f95728b789c693cc7de9e37c2e8b07e8e35a8129fa754ac7aa8c296b97a7364a", + "translationSha256": "45b9408d44a49c51ac60577c0958a124623d654f1538017b27b13ed4bb5283a2", + "status": "published" + }, + { + "path": "platform/billing.mdx", + "sourceSha256": "a93fe73b92ee9d775f4b3e8182db6b719f6a1e8fa988b9f0a482eb5e24d29c62", + "translationSha256": "c806f23e5c5d52c53d0d6e12af9941338cdb3e96bca5a4c63a167e44f905e2dc", + "status": "published" + }, + { + "path": "platform/known-issues.mdx", + "sourceSha256": "d9d69003cc9345a6059440d9f03894ceb437d7173be215e95403ba9b9210aec0", + "translationSha256": "f99332df402d17865860a684150dd6ccd29122ba5f3c708eb69caef038c7eadd", + "status": "published" + }, + { + "path": "platform/limits.mdx", + "sourceSha256": "5f2166c38b61c6dc032b4f0e4ac1fc1ae2c8a14db9af49ffd2371a7bf4649214", + "translationSha256": "52ddfc087e0474bde6680311895ff9a954a5db46b717b9a31541a6ef803f2581", + "status": "published" + }, + { + "path": "platform/storage-and-recovery.mdx", + "sourceSha256": "30a114b2f76b0d2bbcf67cdd2a07630ef1c3992a526aa8915ca30a63d0ba18d4", + "translationSha256": "11029247498dbc0d12e3a92f7f94b2ddc4064d2fcb5db898135834a47b95707d", + "status": "published" + }, + { + "path": "sandboxes/code-interpreter.mdx", + "sourceSha256": "d187221290fdbba78567a330e562a618cdd7d9fff31cc32c74b7ed9c1c67f241", + "translationSha256": "d303e7ef51fdd91e3119091031521ab5266a31ea589aa4b244b67fef810f42a7", + "status": "published" + }, + { + "path": "sandboxes/dashboard.mdx", + "sourceSha256": "828415eb0c46fce33f20bc2dae780262eacabf58127a590b1d681d54966db527", + "translationSha256": "d9a0a9861df6aa1527d239d986b7aab4b17ab463ce26b9b0c23fc4afa6a76cea", + "status": "published" + }, + { + "path": "sandboxes/index.mdx", + "sourceSha256": "f07dd490dcb4e1b5376d256de65e13d79a37688fb8286b2dd6578e0eb14fdfbb", + "translationSha256": "450c89416e702f1fb14110b5fd63237f74131f7c49805f7015aa88c5eaf4b0e1", + "status": "published" + }, + { + "path": "sandboxes/quickstart.mdx", + "sourceSha256": "c58f024fe163b5142bf554232363ffd74fce365d54cebc2f14ae997f9ab210dd", + "translationSha256": "542e0c31f41014a74da89bb10af5437df5a392bd60ed5e6ca6753a91a9276bc0", + "status": "published" + }, + { + "path": "sandboxes/sdk-reference.mdx", + "sourceSha256": "2ef3c1a78d607f5daec121d792e10e66b25dc62538da865aaed3cc69a1947bd9", + "translationSha256": "a5abd0e91902c3efac68c51b32ed6b4a607a74b119a9655615ba51e0fc473940", + "status": "published" + }, + { + "path": "sandboxes/volumes.mdx", + "sourceSha256": "335158c3113ae1afa8cf0c966ffb5390d4e52b4e21965058318be124b5235438", + "translationSha256": "537ac222286e43ad4fc43aabd88e3d3ca5088cd19eb4dfb6863cd8d7e9d1f437", + "status": "published" + }, + { + "path": "studio/getting-started.mdx", + "sourceSha256": "3d6df5a941a22427bf6146f91cf795ceac7439aaf86d8c2d1213dcd3ba8ba2ae", + "translationSha256": "08b1f32113f89be4bbe78c16ddc00a2f728ebbeb6460b07f531cc33f49f9c90d", + "status": "published" + }, + { + "path": "variables/index.mdx", + "sourceSha256": "2b605e838fc7dc268894a433dd4dfea5f3aa9b786ee80b334f9ae9edb242400c", + "translationSha256": "70e5d8a710919e1c018c11f8e28b59ba8c8036b3244e29b9aebc82b868b2f81a", + "status": "published" + }, + { + "path": "variables/references.mdx", + "sourceSha256": "21300a1c62e7d69d9bd9c935f95985ad1dc03fd5085ab6b862749b178f34f89c", + "translationSha256": "7f33bda29839ee73f374faa6a69824bc55e5265968d0e42df7ab66801cee97b2", + "status": "published" + }, + { + "path": "variables/troubleshooting/reference-not-applied.mdx", + "sourceSha256": "2be66a188aa38cb545bd36437c19d928f70eedab58c3b38a7a2ae7720c5f25fa", + "translationSha256": "0602e4272d1494fd5c49ba02aca54f1e69f2e22b15bf4404c3492c9ef6c72b45", + "status": "published" + } + ] +} diff --git a/_locales/de/networking.mdx b/_locales/de/networking.mdx new file mode 100644 index 0000000..c43a7ae --- /dev/null +++ b/_locales/de/networking.mdx @@ -0,0 +1,83 @@ +--- +description: "Jeder Service erhält eine onlizard.com-Domain mit automatischem TLS. Füge einen benutzerdefinierten Hostnamen hinzu, verifiziere DNS, stelle einen Port bereit oder entferne eine Domain." +--- + + + +# Netzwerk + +Jeder Service erhält beim Deployment sofort eine generierte `*.onlizard.com`-Domain mit automatischem TLS, unabhängig von der Region. Füge deinen eigenen Hostnamen hinzu, wenn du live gehen willst. + + + +## Generierte Domains + +Die Standarddomain eines Service wird automatisch für dich erstellt. Zeige sie an (oder generiere eine neue): + +```bash +lizard domain # show the service's current domain +lizard domain generate # generate a new *.onlizard.com subdomain +``` + +Object Storage, das über ein [S3-Add-on](/addons/storage) bereitgestellt wird, verwendet stattdessen einen regionsspezifischen Gateway-Host (`s3-.onlizard.com`). + + + +## Eine benutzerdefinierte Domain hinzufügen + +Der Hostname ist ein **Positionsargument** — es gibt kein `add`-Subcommand: + +```bash +lizard domain app.example.com --service web +``` + +Lizard gibt die zu erstellenden DNS-Einträge zurück (einen `CNAME` für den Hostnamen und einen `TXT`-Eintrag zur Verifizierung). Füge sie bei deinem DNS-Anbieter hinzu. + + + +## Verifizieren + +Sobald DNS propagiert wurde, aktiviere die Domain: + +```bash +lizard domain verify app.example.com +``` + +Dabei wird der `TXT`-Eintrag geprüft und die Domain aktiviert. TLS wird automatisch bereitgestellt. + + + +## Eine Domain entfernen + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes # alias, skip confirmation +``` + + + +## Einen bestimmten Port bereitstellen + +Wenn dein Service auf einem nicht standardmäßigen Port bereitstellt, ordne die Domain diesem Port zu: + +```bash +lizard domain app.example.com --service web --port 8080 +``` + +## Worker-Services + +Ein [Service im Worker-Modus](/deploy/workers) (`containerPort=0`) kann weiterhin eine generierte Domain anzeigen, stellt aber nichts bereit — es gibt keinen Listener und keine Load-Balancer-Route. Füge einem Worker keine benutzerdefinierte Domain hinzu. + + + +## Im Dashboard verwalten + +Die Ansicht **Domains** im Dashboard (`lizard open`) zeigt den Verifizierungs- und TLS-Status jeder Domain und ermöglicht es dir, Hostnamen visuell hinzuzufügen oder zu entfernen. + + + +## Siehe auch + +- [`lizard domain`](/cli/domain) — die vollständige Befehlsreferenz. +- [Regionen](/deploy/regions) — Services und Addons zur Verringerung der Latenz gemeinsam platzieren. +- [Vom Prototyp zu einem SaaS, für das Leute zahlen](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#from-vibe-coded-prototype-to-a-saas-people-pay-for) — wo eine benutzerdefinierte Domain zwischen all den anderen Dingen steht, die eine generierte App noch braucht. diff --git a/_locales/de/observability/_meta.ts b/_locales/de/observability/_meta.ts new file mode 100644 index 0000000..eeddf79 --- /dev/null +++ b/_locales/de/observability/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Übersicht", + logs: "Logs", + metrics: "Metriken & Kosten", + events: "Ereignisse & Verlauf", +}; diff --git a/_locales/de/observability/events.mdx b/_locales/de/observability/events.mdx new file mode 100644 index 0000000..62998e2 --- /dev/null +++ b/_locales/de/observability/events.mdx @@ -0,0 +1,45 @@ +--- +description: "Lies die Bereitstellen-Zeitleiste eines Service und den Live-Status seiner Replikate mit lizard events und finde denselben Verlauf in der Bereitstellungen-Ansicht des Dashboards." +--- + + + +# Events & Verlauf + +`lizard events` zeigt den Bereitstellen-Verlauf eines Service und den Live-Status seiner Replikate — die Zeitleiste dessen, was ausgeliefert wurde und was gerade läuft. + + + +## Events anzeigen + +```bash +lizard events # deploy history + replica status +lizard events --service api # a specific service +lizard events --limit 25 # show more entries (default 10) +``` + +Jeder Eintrag umfasst eine Bereitstellen- oder Skalierungsaktion und den daraus resultierenden Replikatstatus, sodass du "Was hat sich geändert, und ist es gesund?" auf einen Blick beantworten kannst. + + + +## Schnellstatus + +Für eine schnelle Übersicht aller Services im Projekt — Status und URL — verwende: + +```bash +lizard ps +lizard status # the current directory's workspace/project/service link +``` + +## Dashboard + +Die Ansicht **Bereitstellungen** im Dashboard (`lizard open`) stellt denselben Verlauf als Zeitleiste dar, mit einem Detailbereich pro Bereitstellen (Build-Logs, Commit, Status) und dem Gesundheitsstatus pro Replikat. + + + +## Siehe auch + +- [Bereitstellungen](/concepts/deployments) — der Bereitstellen-Lebenszyklus. +- [Logs](/observability/logs) — Laufzeit-, Build- und Neustart-Logs. +- [Metrics & Cost](/observability/metrics) — Ressourcennutzung und Abrechnung. +- [`lizard events`](/cli/events) — die vollständige Befehlsreferenz. diff --git a/_locales/de/observability/index.mdx b/_locales/de/observability/index.mdx new file mode 100644 index 0000000..9e80a08 --- /dev/null +++ b/_locales/de/observability/index.mdx @@ -0,0 +1,17 @@ +--- +description: "Sehen Sie, was Ihre Services tun: Logs streamen, Metriken und Kosten verfolgen sowie Bereitstellen- und Replikatverlauf prüfen." +--- + +# Observability + +Sehen Sie, was Ihre Services tun: Logs streamen, Metriken und Kosten verfolgen sowie Bereitstellen- und Replikatverlauf prüfen. + + + +## In diesem Abschnitt + +- [Logs](/observability/logs) — Live- und historische Logs, einschließlich Build- und Neustart-Logs. +- [Metrics & Cost](/observability/metrics) — Ressourcennutzung und die dafür anfallenden Kosten. +- [Events & History](/observability/events) — Bereitstellen-Zeitleiste und Status pro Replikat. + +Jede Ansicht hier hat auch ein `--json`-Formular; genau dieses liest ein AI-Coding-Agent, wenn sich ein Bereitstellen fehlerhaft verhält — siehe [Deploys aus Claude Code](https://lizard.build/blog/deploy-from-claude-code). diff --git a/_locales/de/observability/logs.mdx b/_locales/de/observability/logs.mdx new file mode 100644 index 0000000..73ff74d --- /dev/null +++ b/_locales/de/observability/logs.mdx @@ -0,0 +1,67 @@ +--- +description: "Laufzeit-Logs streamen, Build-Logs nach einem fehlgeschlagenen Bereitstellen lesen und den Log-Tail rund um einen Neustart abrufen – über die CLI oder das Dashboard." +--- + +# Logs + +Lizard erfasst **Laufzeit**-Logs, **Build**-Logs und den Log-Tail rund um **Neustarts**. Streame sie live in deinem Terminal oder sieh sie dir im Dashboard an. + + + +## Laufzeit-Logs + +```bash +lizard logs # last 200 runtime lines, then live tail +lizard logs --service api # a specific service +lizard logs --tail 1000 # more history (max 1000) +lizard logs --level error # filter by level +``` + + + +### Verhalten mit `--json` + +`lizard logs --json` ist **kein** Stream — es gibt die letzten 200 Zeilen zurück (überschreibbar mit `--tail N`, maximal 1000) und beendet sich dann. Nutze das für Snapshots und Skripting. Streame nur dann live ohne `--json`, wenn du ein interaktives Tail möchtest. + +## Build-Logs + +```bash +lizard logs --build # the most recent build's logs +``` + +Das ist das Erste, was du prüfen solltest, wenn ein Bereitstellen fehlschlägt — lies die Logs, behebe die Ursache und dann `lizard redeploy`. Siehe [Build-Pipeline](/concepts/build-pipeline). + + + +## Neustart- / Crash-Logs + +Wenn eine Replik abstürzt oder neu startet, hol dir den umgebenden Log-Tail: + +```bash +lizard logs --restart latest # the most recent restart +lizard logs --restart # a specific restart +lizard logs --restarts # list recent restarts +``` + + + +## Durch den Verlauf blättern + +`lizard service logs` unterstützt das Blättern durch ältere Fenster: + +```bash +lizard service logs --service api --tail all # full history (no follow) +lizard service logs --service api --page 2 # older window (implies --tail 200) +``` + +## Dashboard + +Das Dashboard (`lizard open`) streamt Laufzeit- und Build-Logs mit Such- und Level-Filtern und zeigt die Build-Ausgabe pro Deployment in der Ansicht **Bereitstellungen**. + + + +## Siehe auch + +- [`lizard logs`](/cli/logs) — die vollständige Befehlsreferenz. +- [Ereignisse & Verlauf](/observability/events) — Bereitstellen-Verlauf und Replik-Status. +- [Bereitstellen aus Claude Code](https://lizard.build/blog/deploy-from-claude-code) — Logs, die dafür geschrieben sind, von einem Agenten gelesen zu werden, nicht nur von dir. diff --git a/_locales/de/observability/metrics.mdx b/_locales/de/observability/metrics.mdx new file mode 100644 index 0000000..6fef0e0 --- /dev/null +++ b/_locales/de/observability/metrics.mdx @@ -0,0 +1,48 @@ +--- +description: "CPU, Arbeitsspeicher, Netzwerk und Festplatte für einen Service verfolgen, sehen, was die aktuelle Skalierung kostet, und anhand der Zahlen handeln." +--- + + + +# Metriken & Kosten + +Verfolge CPU, Arbeitsspeicher, Netzwerk und Festplatte für einen Service — und sieh, was es kostet — über die CLI oder das Dashboard. + + + +## Metriken anzeigen + +```bash +lizard metrics # CPU / memory / network / disk +lizard metrics --service api # a specific service +lizard metrics --range # time window +lizard metrics --watch # live-updating view +``` + + + +## Kosten einbeziehen + +```bash +lizard metrics --cost +``` + +Fügt Kostenangaben neben der Ressourcennutzung hinzu, damit du den Preis der aktuellen Skalierung sehen kannst. + +## Dashboard + +Das Dashboard (`lizard open`) stellt diese als Diagramme in der Ansicht **Metriken / Observability** dar, und die Ansicht **Nutzung** schlüsselt Verbrauch und Abrechnung im gesamten Projekt auf. Öffne es mit: + +```bash +lizard open +``` + + + +## Auf Basis der Werte handeln + +- Hohe CPU-/Arbeitsspeicherauslastung → hochskalieren: `lizard scale --service api --cpu 2 --memory 2048`. +- Anhaltende Last → Replikate hinzufügen: `lizard scale --service api --replicas 3`. +- Speicherengpass bei einem Add-on → Speicher erweitern: `lizard scale --service postgres --storage 8192`. + +Siehe [Scaling](/deploy/scaling). diff --git a/_locales/de/platform/_meta.ts b/_locales/de/platform/_meta.ts new file mode 100644 index 0000000..0546759 --- /dev/null +++ b/_locales/de/platform/_meta.ts @@ -0,0 +1 @@ +export default { billing: "Abrechnung & Guthaben", limits: "Limits", 'storage-and-recovery': "Speicher & Wiederherstellung", 'known-issues': "Bekannte Probleme" }; diff --git a/_locales/de/platform/billing.mdx b/_locales/de/platform/billing.mdx new file mode 100644 index 0000000..bcd6b37 --- /dev/null +++ b/_locales/de/platform/billing.mdx @@ -0,0 +1,61 @@ +--- +description: "Lizard pay as you go: Ressourcensätze, Kontoguthaben, optionales automatisches Aufladen, Zahlungsgebühren und was passiert, wenn Ihr Guthaben aufgebraucht ist." +--- + +# Pay as you go + +Lizard hat für Standardkonten keine monatliche Grundgebühr und keine Sitzplatzgebühr. Laden Sie Guthaben auf Ihr Konto und zahlen Sie für die Ressourcen, die Sie nutzen. Ungenutztes gekauftes Guthaben bleibt in Ihrem Kontostand, sodass Sie in einem ruhigen Monat kein weiteres Paket kaufen müssen. + + + +## Ressourcensätze + +Die Preise sind in US-Dollar angegeben. + +| Ressource | Rate | +| --- | ---: | +| CPU | $0.000006948 pro vCPU-Sekunde | +| Memory | $0.000003474 pro GB-Sekunde | +| Persistent Volumes | $0.000000054 pro GB-Sekunde | +| Managed Object Storage | $0.0135 pro GB-Monat | +| Outgoing traffic | $0.045 pro GB, ab dem ersten Byte | + +Für eingehenden Traffic fallen keine Gebühren an. Für Apps, Managed Postgres, Managed Redis und Sandboxes gelten dieselben jeweils anwendbaren Ressourcensätze. Die Ressourcenlimits des Kontos gelten weiterhin; das Hinzufügen von Guthaben erhöht diese Limits nicht. + +Zum Beispiel kosten eine vCPU und 1 GB Arbeitsspeicher, die eine Stunde lang genutzt werden, $0.0375192 an Compute-Kosten. Speicher, ausgehender Traffic und Zahlungsgebühren können diesen Betrag erhöhen. Dies ist ein Beispiel für Ressourcenkosten, nicht der berechnete Betrag für eine Aufladung. + +Die vollständige Preisübersicht finden Sie unter [current pricing](https://lizard.build/pricing). Für Enterprise-Abrechnung gilt Ihr Vertrag. + + + +## Kontoguthaben + +Die Nutzung in einem Workspace wird vom Kontoguthaben seines Eigentümers abgezogen. Das Hinzufügen von Mitgliedern verursacht keine Sitzplatzgebühr. Auf der Seite „Credits“ sehen Sie Ihr Guthaben, Käufe und jegliches Guthaben, das abläuft. + +- **Gekauftes Guthaben verfällt nicht.** Es wird nicht jeden Monat zurückgesetzt. +- **Testguthaben verfällt.** Neue Konten erhalten $10 Testguthaben, gültig für 31 Tage. +- **Promo-Guthaben kann verfallen.** Prüfen Sie die Bedingungen und das angezeigte Ablaufdatum für die Gutschrift. + +Ein gekauftes Guthaben bezahlt die Nutzung; es ist kein Rabatt auf den Ressourcensatz. Ziehen Sie es beim Kostenvergleich mit einem anderen Anbieter nicht noch einmal ab. + + + +## Aufladungen und Gebühren + +Öffnen Sie **Credits** in den Kontoeinstellungen, um Guthaben hinzuzufügen. Bevor Sie bestätigen, zeigt der Aufladebildschirm den Mindestbetrag, den Guthabenbetrag, die Zahlungsgebühr und den Gesamtbetrag an. Eine Mindestaufladung ist keine monatliche Gebühr. + +Automatisches Aufladen ist optional. Wählen Sie den Guthabenschwellenwert und den Betrag in Ihren Credits-Einstellungen. Sie können es dort deaktivieren. Das Deaktivieren des automatischen Aufladens stoppt keine Ressourcen und beendet keine Gebühren für deren Nutzung. + + + +## Niedriges oder leeres Guthaben + +Lizard warnt Sie, wenn Ihr Guthaben niedrig ist. Wenn Ihr Guthaben aufgebraucht ist und eine Zahlung es nicht wiederherstellt, kann die Erstellung von Ressourcen eingeschränkt werden und laufende Dienste können nach der jeweils geltenden Kulanzfrist pausieren. Prüfen Sie Ihre Credits-Seite auf die Kontobedingungen und stellen Sie das Guthaben vor Ablauf der Kulanzfrist wieder her, um eine Pausierung zu vermeiden. + + + +## Inaktive Apps und gespeicherte Daten + +Eine App kann Arbeitsspeicher und CPU verwenden, auch wenn sie keine Anfragen hat. Stoppen Sie die App, um die Compute-Nutzung zu beenden. Persistent Volumes und Managed Object Storage verursachen weiter Speicherkosten, solange Sie Daten gespeichert halten, auch wenn die App gestoppt ist. + +Lesen Sie vor dem Entfernen von Daten [Speicher und Wiederherstellung](/platform/storage-and-recovery). Lesen Sie [metrics](/observability/metrics), um konfigurierte Limits mit der gemessenen Nutzung zu vergleichen. diff --git a/_locales/de/platform/known-issues.mdx b/_locales/de/platform/known-issues.mdx new file mode 100644 index 0000000..cbcdae5 --- /dev/null +++ b/_locales/de/platform/known-issues.mdx @@ -0,0 +1,51 @@ +--- +description: "Aktuelle Hinweise zum Lebenszyklus von Sandboxes, Grenzen bei der Wiederherstellung von Bereitstellungen und Vorrangregeln für Build-Einstellungen, die Sie prüfen sollten, bevor Sie sich auf einen Workflow verlassen." +--- + + + +# Bekannte Probleme + +Diese Seite dokumentiert Verhalten, das besondere Vorsicht oder eine verifizierte Freigabe erfordert. Ein zur Prüfung eingereichter Code-Fix ist keine Garantie für einen laufenden Dienst. + + + +## Pause und Ablauf von Sandboxen + +Die Pause soll die verbleibende Laufzeit einfrieren. Ein Konflikt zwischen der Uhr des Knotens und einem separaten Bereinigungsprozess kann dazu führen, dass eine pausierte Sandbox nach ihrer ursprünglichen Frist beendet wird. Auch der Neustart des Node-Agent und das Fortsetzen einer Sandbox ohne Ablaufzeit benötigen den Lebenszyklus-Fix. + +Bis dieser Fix einen Live-Test bestanden hat und Ihre Region erreicht hat, sollten Sie sich für langfristigen Zustand nicht allein auf Pause verlassen. Speichern Sie Dateien unter `/data` auf einem Persistent Volume, oder speichern Sie den Anwendungszustand in einer Datenbank oder einem Object Storage. Host-Arbeitsspeicher ist kein Backup. Verwenden Sie eine explizite Laufzeit und beenden Sie die Sandbox, wenn die Aufgabe erledigt ist. + + + +## Redeploy ist kein Rollback + +`lizard redeploy` baut die ausgewählte Quelle mit der aktuellen Konfiguration erneut. Dabei wird kein vorheriger Build ausgewählt. Ein fehlgeschlagener Build und ein fehlgeschlagener Start haben unterschiedliche Auswirkungen; prüfen Sie den aktiven Dienst und seine Logs, bevor Sie einen Wiederherstellungsschritt wählen. Gehen Sie nicht davon aus, dass jede Runtime bei einem fehlgeschlagenen Start weiterhin das alte Release ausliefert. + + + +## Vorrang des Dockerfile + +Explizite Build- oder Start-Befehle haben Vorrang vor einem Dockerfile im Repository. Entfernen Sie diese Überschreibungen, wenn Sie `dockerfilePath` auswählen. Schon eine Aktualisierung der Einstellungen kann einen Build starten, prüfen Sie daher die Ereignisse, bevor Sie ein weiteres Redeploy auslösen. Siehe [Fehlerbehebung für Dockerfile](/deploy/troubleshooting/incomplete-dockerfile). + + + +## Vorlagen und MCP + +Die aktuelle API zum Erstellen von Sandboxes akzeptiert die zwei integrierten Vorlagen. Anleitungen, die `lizard push` für benutzerdefinierte Vorlagen verwenden, entsprechen nicht der aktuellen öffentlichen CLI. + +Lizard Skill verwendet Lizard CLI. Dieser Workflow stellt keinen MCP-Transport bereit. Das Hosting eines eigenen entfernten MCP-Servers ist ein separates Application-Deployment; siehe den [Leitfaden](/guides/deploy-mcp-server). + + + +## Änderungen am Service-Port: behoben und verifiziert am 2026-09-09 + +Die Prüfung vom 7. September ergab HTTP 503, nachdem ein Upload-Dienst von Port `3000` auf `80` geändert wurde, obwohl ein bereiter Prozess vorhanden war. Der Fix in Produktion wendet den gewählten Port jetzt auf den laufenden Dienst an und behält einen expliziten Port beim Upload und beim Rebuild bei. Eine Live-Prüfung der Portänderung war am 9. September erfolgreich. Prüfen Sie nach einem Deployment sowohl die öffentliche URL als auch den Zustand des Dienstes. + + + +## Upload-Archive und Exit-Codes bei fehlgeschlagenen Builds: behoben + +Lizard CLI 0.3.95 schließt macOS-`._*`-Metadateneinträge aus Source-Uploads aus und gibt bei fehlgeschlagenen Cloud-Builds einen Exit-Code ungleich null zurück. Aktualisieren Sie ältere CLI-Versionen; `COPYFILE_DISABLE` wird nicht mehr benötigt. Die [Framework-Prüfungen](/framework-guides/validation) decken Uploads von macOS mit der aktuellen CLI ab. + +Ein erfolgreicher Build allein beweist noch nicht, dass die App funktioniert. Prüfen Sie nach dem Deployment die öffentliche URL, Routen, Formulare und Datenoperationen. diff --git a/_locales/de/platform/limits.mdx b/_locales/de/platform/limits.mdx new file mode 100644 index 0000000..1562835 --- /dev/null +++ b/_locales/de/platform/limits.mdx @@ -0,0 +1,47 @@ +--- +description: "Prüfen Sie vor dem Deployment die Replikatlimits von Apps, Ressourcen und Timeouts von Sandboxes, Regionen und den Geltungsbereich von Kontingenten auf Kontoebene." +--- + +# Limits + +Limits hängen von der Ressource, dem Tarif und dem Konto ab. Eine Einstellung pro Replikat entspricht nicht der insgesamt für einen Service oder ein Konto verfügbaren Kapazität. Prüfen Sie Ihren aktuellen Tarif und das Ergebnis der Erstellungs- oder Skalierungsanfrage, bevor Sie eine Workload dimensionieren. + + + +## Anwendungen + +| Einstellung | Geltungsbereich | Was zu prüfen ist | +|---|---|---| +| CPU und Arbeitsspeicher | Jedes Replikat | Drei Replikate mit einer Obergrenze von 2 vCPU / 2 GiB haben zusammen eine konfigurierte Obergrenze von 6 vCPU / 6 GiB. Das ist keine Nutzungsvorhersage. | +| Anzahl der Replikate | Service und Tarif | Die API akzeptiert 1–10; Tariflimits können diesen Bereich einschränken. Prüfungen im Standardtarif erlauben 1, bzw. 5 für Pro/Enterprise, mit kontoabhängigen Ausnahmen. | +| Ressourcenobergrenze des Kontos | Kontoinhaber | Ein zweites Projekt erzeugt nicht zwangsläufig ein zweites Kontingent. Fragen Sie vor der Planung eines großen Bereitstellungen nach der effektiven Kontenobergrenze. | +| Worker-Modus | Service | `containerPort=0` läuft ohne HTTP-Listener oder öffentliche Load-Balancer-Route. | +| Benutzerdefinierte Domain | Hostname | Benutzerdefinierte Wildcard-Domains werden nicht akzeptiert. Verwenden Sie einen spezifischen Hostnamen und schließen Sie die Prüfungen zu Eigentümerschaft und DNS ab. | + +Anwendungen können verschiedene Runtimes verwenden. Gehen Sie nicht davon aus, dass jede Anwendung dieselbe Firecracker-Mikro-VM-Grenze wie Sandboxes hat. + +## Sandboxes + +| Einstellung | Aktuelle Create-API | +|---|---| +| CPU und Arbeitsspeicher | 4 vCPU / 4096 MiB | +| Vorlagen | `base`, `code-interpreter-v1` | +| Standardlaufzeit der Raw API | `timeoutMs: 0`, kein Ablauf | +| Standardlaufzeit des Lizard SDK | 300000 ms, fünf Minuten | +| Bereich für explizite Laufzeit | Ganzzahlige Millisekunden von 0 bis 2147483647 | +| Laufzeit aktualisieren | Mindestens 1000 ms; kein Idle-Timer | +| Anbindung von Persistent Volumes | Jeweils nur eine Sandbox, auf dem Node des Volumes | + +Übergeben Sie in Skripten eine explizite Laufzeit. Zum Beispiel macht `--timeout 300000` das beabsichtigte Limit über verschiedene Versionen von Lizard CLI hinweg eindeutig. Lesen Sie vor dem Parken einer Sitzung [Pausieren und Ablauf](/platform/known-issues#sandbox-pause-and-expiration). + + + +## Regionen + +Die aktuell konfigurierten Regionen umfassen US East (Virginia), `us-east-1`, und EU West (Limburg), `eu-west-lim-a`. Eine Region im Katalog garantiert nicht, dass für jede Ressource Kapazität verfügbar ist. Prüfen Sie die Regionsauswahl beim Erstellen der Ressource; eine Sandbox, die ein vorhandenes Volume verwendet, muss auf dem Node dieses Volumes laufen. + + + +## Vor dem Erhöhen der Skalierung + +Prüfen Sie aktiven Tarif, Einstellungen pro Replikat, Kontenobergrenze, Datenbank-Verbindungslimit und Wachstum des Storage zusammen. Verwenden Sie [Skalierung](/deploy/scaling), [Metriken](/observability/metrics) und [Preise](https://lizard.build/pricing), um konfigurierte Kapazität mit der gemessenen Nutzung zu vergleichen. diff --git a/_locales/de/platform/storage-and-recovery.mdx b/_locales/de/platform/storage-and-recovery.mdx new file mode 100644 index 0000000..b979e82 --- /dev/null +++ b/_locales/de/platform/storage-and-recovery.mdx @@ -0,0 +1,53 @@ +--- +description: "Wählen Sie Speicher für Anwendungsdaten und Sandbox-Dateien. Verstehen Sie Anhänge, Host-Ausfälle, Exporte und Wiederherstellung, bevor Sie eine Ressource löschen oder ersetzen." +--- + + + +# Speicher und Wiederherstellung + +Wählen Sie den Speicher danach aus, welche Daten einen Prozessneustart, ein neues Deployment oder einen Host-Ausfall überstehen müssen. Das sind unterschiedliche Ereignisse. Persistenter Speicher bietet für sich allein weder ein Backup noch einen Wiederherstellungspunkt oder Hochverfügbarkeit. + +| Daten | Wo sie gespeichert werden sollten | Grenze | +|---|---|---| +| Anwendungsdaten | Managed Postgres oder eine andere Datenbank | Ein Neustart ist etwas anderes als das Wiederherstellen gelöschter oder beschädigter Daten. Testen Sie einen separaten Export- und Wiederherstellungsweg. | +| Cache- und Queue-Daten | Managed Redis | Entscheiden Sie, ob die Workload ihren Zustand neu aufbauen kann oder einen eigenen Wiederherstellungsplan braucht. | +| Von Anwendungen gemeinsam genutzte Dateien | Managed Object Storage | Legen Sie die Zugriffsrichtlinie des Buckets fest, bevor Sie private Daten hochladen. Der automatisch erstellte Bucket `default` ist öffentlich lesbar. | +| Dateien, die von späteren Sandboxes benötigt werden | Persistent Volumes, eingehängt unter `/data` | Jeweils nur ein Sandbox-Anhang; das Volume bleibt auf seinem Node. | +| Temporäre Sandbox-Dateien | Das Gast-Dateisystem außerhalb von `/data` | Erwarten Sie nicht, dass sie nach dem Ende der Sandbox oder nach dem Ersetzen des Gasts noch vorhanden sind. | +| Angehaltener Prozesszustand | Host-Arbeitsspeicher | Pausieren ist kein dauerhaftes Snapshot; bei einem Host-Ausfall geht dieser Zustand verloren. | + + + +## Dateien nach dem Ende einer Sandbox behalten + +Erstellen Sie ein Persistent Volume im selben Projekt, hängen Sie es beim Erstellen der Sandbox an und schreiben Sie unter `/data`. Beenden Sie die erste Sandbox, bevor Sie das Volume an die nächste anhängen. Siehe das [vollständige Beispiel](/sandboxes/volumes). + + + +## Wiederherstellung einer Datenbank planen + +Vor einer Migration oder einem Release, das Daten verändert: + +1. Wählen Sie eine Exportmethode für die verwendete Datenbank und Version. +2. Speichern Sie den Export getrennt von der Ressource, die geändert wird. +3. Stellen Sie ihn in einer separaten Testdatenbank wieder her und prüfen Sie, ob die Anwendung ihn lesen kann. +4. Halten Sie die Dauer der Wiederherstellung und die neuesten im Export enthaltenen Daten fest. + +Gehen Sie nicht davon aus, dass es geplante Backups, Point-in-Time-Recovery, Multi-Node-Replikation oder eine Garantie für die Wiederherstellungszeit gibt, nur weil eine Datenbank verwaltet wird. Prüfen Sie die aktuelle Servicevereinbarung und die verfügbaren Steuerungsmöglichkeiten für Ihre Ressource. + + + +## Umgebungsreferenzen + +Eine Anwendung sollte ihre Datenbankverbindung aus einer Umgebungsreferenz lesen. Ein Connection String ist ein Zugangsdatengeheimnis; geben Sie ihn nicht aus, um eine Aktualisierung zu prüfen. Eine Verbindungsprüfung wie `SELECT 1` belegt mehr, als die Variable nur in einer Shell zu sehen. + + + +## Verwandte Anleitungen + +- [Managed Postgres](/addons/postgres) +- [Managed Redis](/addons/redis) +- [Managed Object Storage](/addons/storage) +- [Persistent Volumes](/sandboxes/volumes) +- [Deployment-Wiederherstellung](/concepts/deployments#failed-releases-and-recovery) diff --git a/_locales/de/sandboxes/_meta.ts b/_locales/de/sandboxes/_meta.ts new file mode 100644 index 0000000..3afc9a7 --- /dev/null +++ b/_locales/de/sandboxes/_meta.ts @@ -0,0 +1,8 @@ +export default { + index: "Übersicht", + quickstart: "Schnellstart", + 'sdk-reference': "SDK-Referenz", + 'code-interpreter': "Code-Interpreter", + volumes: "Persistent Volumes", + dashboard: "Dashboard", +}; diff --git a/_locales/de/sandboxes/code-interpreter.mdx b/_locales/de/sandboxes/code-interpreter.mdx new file mode 100644 index 0000000..92929ca --- /dev/null +++ b/_locales/de/sandboxes/code-interpreter.mdx @@ -0,0 +1,109 @@ +--- +description: "CodeSandbox behält zwischen Aufrufen einen zustandsbehafteten Kernel bei, sodass Variablen und Importe erhalten bleiben. Führen Sie Python, JavaScript oder Bash so aus, wie es ein Agent tut." +--- + +# Code Interpreter + +`CodeSandbox` erweitert eine normale [sandbox](/sandboxes) um einen **zustandsbehafteten Kernel** — Variablen, Importe und Funktionsdefinitionen bleiben zwischen Aufrufen erhalten, genau wie in einem Jupyter-Notebook. Das ist das richtige Werkzeug, wenn ein KI-Agent Code schrittweise erzeugt und ausführt. + +Er startet aus dem Vorlage `code-interpreter-v1` (Python 3.14 + Node.js 26, mit einer Code-Ausführungs-API auf Port 8080) und unterstützt standardmäßig **Python, JavaScript und Bash**. + + + +## Code ausführen + +```ts +import { CodeSandbox } from '@lizard-build/sdk'; + +// Every sandbox belongs to a project — usage is metered per project +const sandbox = await CodeSandbox.create({ project: 'my-project' }); // defaults to 'code-interpreter-v1' + +await sandbox.runCode('x = 42'); +const result = await sandbox.runCode('print(x * 2)'); +console.log(result.stdout); // "84\n" — x survived from the previous call + +await sandbox.kill(); +``` + +`runCode(code, opts?)` gibt ein `Execution` zurück: + +| Feld | Beschreibung | +|---|---| +| `stdout` / `stderr` | Erfasste Ausgabeströme | +| `results` | Umfangreiche Ergebnisse (Werte sowie alle erzeugten Bilder / Diagramme) | +| `error` | Ein `ExecutionError` (`name`, `message`, `traceback`), wenn der Code einen Fehler ausgelöst hat | +| `executionCount` | Monotoner Zähler für den Kernel | + + + +## Eine Sprache auswählen + +Standard ist Python. Übergeben Sie `language` für einen einmaligen Aufruf in einer anderen Laufzeitumgebung: + +```ts +const js = await sandbox.runCode('1 + 1', { language: 'javascript' }); +console.log(js.results[0].data); // "2" + +await sandbox.runCode('echo "$(uname -s)"', { language: 'bash' }); +``` + + + +## Ausgabe streamen + +Bei Zellen mit langer Laufzeit können Sie stdout/stderr während der Erzeugung streamen, statt auf das Ergebnis zu warten: + +```ts +await sandbox.runCode('for i in range(5): print(i)', { + onStdout: (line) => process.stdout.write(line), + onStderr: (line) => process.stderr.write(line), + onResult: (r) => console.log('result:', r), + onError: (e) => console.error('error:', e.name, e.message), +}); +``` + + + +## Isolierte Kontexte + +Ein **Kontext** ist ein unabhängiger Namespace innerhalb derselben Sandbox — verwenden Sie einen pro Agent-Sitzung oder pro Benutzer, damit ihre Variablen nie kollidieren. + +```ts +const a = await sandbox.createContext({ language: 'python' }); +const b = await sandbox.createContext({ language: 'python' }); + +await sandbox.runCode('secret = 1', { context: a }); +await sandbox.runCode('print(secret)', { context: b }); // NameError — b never saw it + +await sandbox.listContexts(); +await sandbox.restartContext(a); // clear all variables/state +await sandbox.deleteContext(b); // free its resources +``` + +Übergeben Sie an `runCode` **entweder** `context` **oder** `language`, nicht beides — ein Kontext ist bereits an eine Sprache gebunden. + + + +## Checkpointing einer Sitzung + +Da `CodeSandbox` eine Sandbox ist, funktionieren [Anhalten und Fortsetzen](/sandboxes/quickstart#pause-and-resume) genauso. Installieren Sie einen umfangreichen Abhängigkeits-Stack einmal, halten Sie an und setzen Sie später fort, wobei der Kernel-Status erhalten bleibt: + +```ts +const sandbox = await CodeSandbox.create({ project: 'my-project' }); +await sandbox.runCode('import subprocess; subprocess.run(["pip", "install", "scikit-learn"])'); +const id = sandbox.sandboxId; +await sandbox.pause(); + +// Later — resume with packages and kernel variables already in place +const resumed = await CodeSandbox.connect(id); +const out = await resumed.runCode('import sklearn; print(sklearn.__version__)'); +console.log(out.stdout); +await resumed.kill(); +``` + + + +## Siehe auch + +- [SDK-Referenz](/sandboxes/sdk-reference) — jede Methode von `CodeSandbox` und jede Option von `runCode`. +- [Persistent Volumes](/sandboxes/volumes) — Speicher anhängen, der länger als eine einzelne Sandbox bestehen bleibt. diff --git a/_locales/de/sandboxes/dashboard.mdx b/_locales/de/sandboxes/dashboard.mdx new file mode 100644 index 0000000..96c49c6 --- /dev/null +++ b/_locales/de/sandboxes/dashboard.mdx @@ -0,0 +1,57 @@ +--- +description: "Sandboxes manuell über die Sandboxes-Seite eines Projekts erstellen und prüfen: API-Schlüssel, Live-Shells, Lebenszyklus-Steuerung, Snapshots und Volumes." +--- + +# Sandboxes-Dashboard + +Jedes Projekt hat eine **Sandboxes**-Seite, auf der du Sandboxes manuell erstellen und prüfen kannst — nützlich zum Debuggen der Umgebung eines Agents, für den Zugriff auf eine interaktive Shell oder um stichprobenartig zu prüfen, welchen Code etwas erzeugt hat. Öffne ein Projekt und wähle in der Seitenleiste **Sandboxes** aus (`///sandboxes`). + +Die Seite hat drei Tabs: **Sandboxes**, **Volumes** und **Snapshots**. + + + +## API-Schlüssel abrufen + +Wenn du Sandboxes noch nicht verwendet hast, führt dich der Leerzustand durch das Erstellen eines **API-Schlüssels** für das SDK. Der Schlüssel wird **einmalig** angezeigt — kopiere ihn sofort; später kann er nicht mehr abgerufen werden. Speichere ihn als `LIZARD_API_KEY` (siehe [Quickstart](/sandboxes/quickstart#authenticate)). + + + +## Sandbox erstellen + +Klicke auf **New Sandbox** und lege Folgendes fest: + +- **Snapshot** — die [Vorlage](/sandboxes#templates), von der gebootet wird (`base` oder `code-interpreter-v1`). +- **Location** — die Region, in der sie ausgeführt wird (standardmäßig die nächstgelegene verfügbare). +- **Resources** — die aktuellen Vorlagen verwenden 4 vCPU und 4096 MiB RAM; das sind keine Größenoptionen pro Erstellung. + +Hier erstellte Sandboxes haben kein Timeout — sie laufen, bis du sie beendest. + + + +## Laufende Sandbox prüfen + +Wenn du eine Sandbox auswählst, öffnet sich ein Detailbereich mit zwei Tabs. + +**Overview** zeigt ID, Vorlage, Status, Region sowie CPU/Arbeitsspeicher an, außerdem: + +- **Exposed ports** — jeder Port, der mit [`getHost`](/sandboxes/quickstart#exposing-a-port) geöffnet wurde, jeweils mit einer kopierbaren öffentlichen `https://…onlizard.com`-URL, die du direkt öffnen kannst. +- **SSH access** — falls verfügbar, ein direkt einfügbarer `ssh root@ -p `-Befehl und das generierte Passwort. + +**Terminal** gibt dir eine browserbasierte Shell direkt in die micro-VM (über SSH), sodass du dich umsehen kannst, ohne das Dashboard zu verlassen. + +Aktive Sandboxes melden in der Liste CPU- und Speicherauslastung in Echtzeit; pausierte und gestoppte melden null. + + + +## Lebenszyklus + +- **Kill Sandbox** (im Detailbereich) beendet sie sofort und gibt ihre Ressourcen frei — einschließlich des Trennens eines eventuell verbundenen [Volumes](/sandboxes/volumes). +- **Pause / resume** werden über das [SDK](/sandboxes/quickstart#pause-and-resume) gesteuert; eine pausierte Sandbox wird hier als **Paused** angezeigt und verbraucht keine bedarfsabhängige Rechenleistung. + +## Snapshots + +Im Tab **Snapshots** werden die Vorlagen aufgelistet, von denen eine Sandbox booten kann — die integrierten `base` und `code-interpreter-v1`. Ein Upload-Befehl für benutzerdefinierte Vorlagen ist nicht Teil der aktuellen öffentlichen CLI. Jeder Eintrag zeigt die standardmäßigen vCPU-/Speicherwerte und die Beschreibung. + +## Volumes + +Im Tab **Volumes** verwaltest du [persistenten Speicher](/sandboxes/volumes): Erstelle ein Volume mit Name und Größe und sieh, an welche Sandbox es jeweils angehängt ist. diff --git a/_locales/de/sandboxes/index.mdx b/_locales/de/sandboxes/index.mdx new file mode 100644 index 0000000..ab8e85f --- /dev/null +++ b/_locales/de/sandboxes/index.mdx @@ -0,0 +1,88 @@ +--- +description: "Eine Sandbox ist eine isolierte Firecracker-Mikro-VM, die in Millisekunden startet, Code ausführt und wieder verworfen wird. Die Recheneinheit hinter KI-Agenten." +--- + +# Sandboxes + +Eine **Sandbox** ist eine isolierte Firecracker-Mikro-VM, die Sie bei Bedarf starten, darin Code ausführen und nach Abschluss wieder beenden. Jede davon ist eine vollständige Linux-Umgebung mit eigenem Dateisystem, Netzwerk und Prozess-Namespace — gestartet in Millisekunden statt in Minuten. + +Sandboxes sind die Recheneinheit hinter KI-Agenten, Code-Interpretern, Evals und CI-ähnlichen Jobs auf Lizard. Während ein [Service](/concepts/architecture) eine langlebige Bereitstellung ist, die an ein Repo gebunden ist, ist eine Sandbox **ephemer, programmatisch und wegwerfbar** — erstellen Sie für jede Aufgabe eine Sandbox innerhalb der für Ihr Konto verfügbaren Kapazität. + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const { stdout } = await sandbox.process.exec('echo "hello from Lizard"'); +console.log(stdout); // hello from Lizard +await sandbox.kill(); +``` + + + +## Wann Sie eine Sandbox verwenden sollten + +| Verwenden Sie eine **Sandbox**, wenn… | Verwenden Sie einen **Service**, wenn… | +|---|---| +| Ein Agent nicht vertrauenswürdigen oder generierten Code ausführen muss | Sie eine App bereitstellen, die dauerhaft läuft | +| Sie pro Aufgabe eine frische, wegwerfbare Linux-Umgebung möchten | Sie eine stabile `..onlizard.com`-URL und TLS möchten | +| Sie viele isolierte Jobs gleichzeitig auffächern müssen | Sie einen einzelnen, ständig laufenden Prozess haben | +| Die Workload nur kurz lebt oder pausiert wird | Die Workload git-basiert ist und automatisch neu bereitgestellt wird | + +Sobald ein Agent innerhalb einer Sandbox eine funktionierende App erstellt hat, können Sie sie mit [`lizard up`](/deploy/upload) zu einem persistenten Service hochstufen — ganz ohne Dockerfile. + + + +## Was sie schnell macht + +- **Firecracker-Mikro-VMs** — für jede Sandbox ein separater Linux-Gast. App-Laufzeiten haben unterschiedliche Isolationsregeln. Hardwarevirtualisierung trennt den Gast vom Host. Kontrollieren Sie Anmeldedaten und Netzwerkzugriff für Code, dem Sie nicht vertrauen. +- **Pausieren und fortsetzen** — beim Pausieren werden die vCPUs der Mikro-VM eingefroren. Arbeitsspeicher, Dateisystem und laufende Prozesse bleiben erhalten, sodass beim Fortsetzen genau dort weitergemacht wird, wo zuvor aufgehört wurde — ohne Pakete neu zu installieren oder Caches erneut aufzuwärmen. So überstehen lang laufende Agent-Sitzungen mehrere getrennte Aufrufe. Der Zustand wird im Arbeitsspeicher des Hosts gehalten statt auf die Festplatte geschrieben, daher übersteht er keinen Host-Ausfall. Siehe [pause & resume](/sandboxes/quickstart#pause-and-resume). +- **Von einer Vorlage starten** — jeder Node erstellt pro Vorlage vorab einen Golden Snapshot, sodass `create` eine Wiederherstellung und kein Kaltstart ist. + + + +## Vorlagen + +Eine Sandbox startet aus einer **Vorlage** (im Dashboard auch *Snapshot* genannt). Zwei sind integriert: + +| Vorlage | Inhalt | Am besten geeignet für | +|---|---|---| +| `base` | Debian Linux, Node.js 26 und die Lizard CLI | Allzweck-Shell- und Build-Umgebungen | +| `code-interpreter-v1` | Python 3.14 + Node.js 26, mit einer HTTP-API zur Codeausführung auf Port 8080 | KI-Code-Interpreter — steuern Sie sie mit [`CodeSandbox`](/sandboxes/code-interpreter) | + +`base` ist die Standardvorlage. Die öffentliche Create-API akzeptiert diese beiden Vorlagennamen. Sie bietet keinen Ablauf zum Hochladen benutzerdefinierter Vorlagen. + + + +## Lebenszyklus + +Eine Sandbox wechselt zwischen drei Zuständen: + +``` +create ──▶ running ⇄ paused ──▶ stopped + (killed or expired) +``` + +- **running** — der Gast kann Befehle ausführen, mit Dateien arbeiten und freigegebene Ports bereitstellen. +- **paused** — vCPUs stoppen. Arbeitsspeicher des Gasts und Prozesszustand bleiben auf dem Host erhalten; das ist weder ein dauerhaftes Snapshot noch ein Backup. +- **stopped** — die Sandbox wurde durch Löschung oder Ablauf beendet. Ihr lokales Dateisystem ist nicht mehr verfügbar. + +Das SDK setzt standardmäßig eine Laufzeit von fünf Minuten. Die rohe Create-API akzeptiert `timeoutMs: 0` für kein Ablaufdatum. Übergeben Sie ein explizites Timeout, wenn sich ein Skript in allen Clients gleich verhalten muss, und geben Sie die Sandbox frei, wenn die Aufgabe beendet ist. Befehle setzen die Laufzeit nicht zurück. + +Das Pausieren soll die verbleibende Laufzeit erhalten. Prüfen Sie das [aktuelle Lebenszyklus-Problem](/platform/known-issues#sandbox-pause-and-expiration), bevor Sie sich auf eine Pause verlassen, die länger als die ursprüngliche Frist dauert. Persistente Dateien gehören in ein [Volume](/sandboxes/volumes); ein pausierter Gast übersteht keinen Host-Ausfall. + + + +## Ressourcen und Limits + +Jede Sandbox läuft mit festen **4 vCPU / 4096 MiB RAM**. Die öffentliche Create-API bietet keine Einstellung für die Größe pro Sandbox. Jede Sandbox übernimmt die Ressourcen ihrer Vorlage. + +Die Region wird automatisch anhand der verfügbaren Kapazität gewählt; im Dashboard können Sie eine festlegen. Gehen Sie nicht davon aus, dass für App-Kontingente und Sandbox-Kapazität dieselben Durchsetzungsregeln gelten. Siehe [Limits](/platform/limits). + + + +## So können Sie Sandboxes steuern + +| Oberfläche | Am besten geeignet für | Hier starten | +|---|---|---| +| **SDK** (JS / Python) | Agenten, Apps und Skripte — einschließlich zustandsbehafteter, mehrsprachiger Ausführung über [`CodeSandbox`](/sandboxes/code-interpreter) | [Quickstart](/sandboxes/quickstart) · [SDK Reference](/sandboxes/sdk-reference) | +| **Dashboard** | Manuelles Erstellen, Terminal, SSH, Monitoring | [Dashboard](/sandboxes/dashboard) | diff --git a/_locales/de/sandboxes/quickstart.mdx b/_locales/de/sandboxes/quickstart.mdx new file mode 100644 index 0000000..601adeb --- /dev/null +++ b/_locales/de/sandboxes/quickstart.mdx @@ -0,0 +1,235 @@ +--- +description: "Starte deine erste Sandbox mit dem Lizard SDK: installieren, einen API-Schlüssel erstellen, ein Projekt auswählen, Code ausführen, Dateien verschieben, einen Port freigeben und pausieren." +--- + + + +# Sandboxes-Schnellstart + +Starte eine Sandbox, führe darin Code aus, gib einen Port frei und pausiere sie mit dem Lizard SDK. + + + +## Installieren + +```bash +# JavaScript / TypeScript +npm install @lizard-build/sdk + +# Python +pip install lizard-sdk +``` + + + +## Authentifizieren + +Sandboxes authentifizieren sich mit einem **API-Schlüssel**. Erstelle einen im Dashboard (**Sandboxes → Erste Schritte → Neuer API-Schlüssel**) — er wird nur einmal angezeigt, also kopiere ihn sofort. + +Lege ihn in deiner Umgebung fest, dann übernimmt das SDK ihn automatisch: + +```bash +export LIZARD_API_KEY="" +``` + +Du kannst ihn auch explizit übergeben: `Sandbox.create('base', { apiKey, project })`. + + + +## Ein Projekt auswählen + +Jede Sandbox gehört zu einem Projekt — die Nutzung wird pro Projekt abgerechnet, daher verweigert die API das Erstellen ohne eines. Gib das Projekt über seine ID, seinen Slug oder seinen Namen an. + +Der `Lizard`-Client bindet genau ein Projekt, daher musst du es nur einmal angeben: + +```ts +import { Lizard } from '@lizard-build/sdk'; + +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +from lizard import Lizard + +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +`Sandbox.create` verwendet dieselbe Option `project`, wenn du lieber keinen Client behalten möchtest. Beide Formen werden unten verwendet. + + + +## Deine erste Sandbox + +**JavaScript / TypeScript** + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +// Boot from a template (default: 'base') in a project +const sandbox = await Sandbox.create('base', { project: 'my-project' }); + +// Run a command and wait for it to finish +try { + const result = await sandbox.process.exec('node -e "console.log(2 ** 10)"'); + console.log(result.stdout); // 1024 + console.log(result.exitCode); // 0 +} finally { + await sandbox.kill(); +} +``` + +**Python** + +```python +from lizard import Sandbox + +sandbox = Sandbox.create("base", project="my-project") + +# exec_ (trailing underscore) because `exec` is reserved in Python +try: + result = sandbox.process.exec_("python -c 'print(2 ** 10)'") + print(result.stdout) # 1024 +finally: + sandbox.kill() +``` + +`process.exec` gibt `{ stdout, stderr, exitCode }` zurück. Es wartet, bis der Befehl abgeschlossen ist — lang laufende Prozesse im Hintergrund mit einem angehängten `&` starten. + + + +## Mit Dateien arbeiten + +`sandbox.fs` liest und schreibt direkt in das Dateisystem der Micro-VM und erstellt bei Bedarf übergeordnete Verzeichnisse. + +```ts +await sandbox.fs.write('/app/server.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('hello from Lizard')).listen(3000); +`); + +const src = await sandbox.fs.read('/app/server.js'); +const entries = await sandbox.fs.list('/app'); // [{ name, path, type, size }] +await sandbox.fs.makeDir('/app/data'); +await sandbox.fs.remove('/app/old.log'); +``` + +| Methode | Beschreibung | +|---|---| +| `fs.write(path, data)` | Eine Datei schreiben — String oder Bytes; erstellt übergeordnete Verzeichnisse | +| `fs.read(path)` | Eine Datei als UTF-8-String lesen | +| `fs.list(path)` | Verzeichniseinträge auflisten | +| `fs.makeDir(path)` | Ein Verzeichnis und alle fehlenden übergeordneten Verzeichnisse erstellen | +| `fs.remove(path)` | Eine Datei oder ein Verzeichnis löschen | + + + +## Einen Port freigeben + +Starte einen HTTP-Server innerhalb der Sandbox und erhalte eine öffentliche HTTPS-URL dafür — ohne Tunneling. + +```ts +await sandbox.process.exec('node /app/server.js &'); // listen on :3000 + +const host = await sandbox.getHost(3000); +console.log(`Live at https://${host}`); +// https://-3000.sandbox..onlizard.com +``` + +`getHost(port)` registriert eine Route zu diesem Port und gibt den Hostnamen zurück. Die URL ist öffentlich und TLS-terminiert. Entferne sie anschließend wieder im Dashboard. + + + +## Pausieren und fortsetzen + +Beim Pausieren werden die vCPUs des Gasts eingefroren und sein aktueller Zustand im Arbeitsspeicher des Hosts beibehalten. Es wird kein dauerhaftes Snapshot geschrieben. Prüfe das [Problem zu Pause und Ablauf](/platform/known-issues#sandbox-pause-and-expiration), bevor du eine Sitzung über ihre ursprüngliche Frist hinaus beibehältst. + +```ts +// Set the environment up once +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +await sandbox.process.exec('npm install -g some-heavy-toolchain'); +const id = sandbox.sandboxId; + +await sandbox.pause(); // freeze the guest; see the lifecycle issue below + +// …minutes or hours later, from anywhere: +const resumed = await Sandbox.connect(id); // resumes guest state still held by the host +await resumed.process.exec('some-heavy-toolchain --version'); // already installed +await resumed.kill(); +``` + +`Sandbox.connect(id)` setzt eine pausierte Sandbox automatisch fort. Du kannst auch `sandbox.resume()` für ein Handle aufrufen, das du bereits hältst. + +**Python** + +```python +sandbox = Sandbox.create("base", project="my-project") +sandbox.process.exec_("pip install numpy pandas") +sandbox_id = sandbox.sandbox_id +sandbox.pause() + +resumed = Sandbox.connect(sandbox_id) # resumes guest state still held by the host +resumed.process.exec_("python -c 'import numpy'") +resumed.kill() +``` + +## Timeouts + +Eine Sandbox mit einem positiven Timeout läuft nach dieser Lebensdauer ab. Das SDK verwendet standardmäßig fünf Minuten; `timeoutMs: 0` beim Erstellen deaktiviert den Ablauf. Setze ein explizites Limit und gib die Sandbox frei, wenn die Aufgabe beendet ist. Eine laufende Sandbox passt du an mit: + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); // 10 min +await sandbox.setTimeout(30 * 60 * 1000); // extend to 30 min from now +``` + +Pause soll die verbleibende Laufzeit einfrieren, aber das aktuelle [Lebenszyklus-Problem](/platform/known-issues#sandbox-pause-and-expiration) erfordert ein verifiziertes Backend-Release. Verlasse dich nicht auf unbegrenztes Pausieren zur Datenaufbewahrung. + + + +## Sandboxes verwalten + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const info = await sandbox.getInfo(); // { sandboxId, template, startedAt, endAt, … } + +const all = await Sandbox.list(); // every running sandbox for this account +await sandbox.kill(); +``` + + + +## Vollständiges Beispiel + +Ein Agent, der ein Skript schreibt, es ausführt, das Ergebnis bereitstellt und den Gast für einen späteren Aufruf pausiert: + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 15 * 60 * 1000 }); + +try { + await sandbox.fs.write('/app/app.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('ok')).listen(3000); + `); + await sandbox.process.exec('node /app/app.js &'); + + const host = await sandbox.getHost(3000); + const res = await fetch(`https://${host}`); + console.log(await res.text()); // ok + + await sandbox.pause(); // resume later with Sandbox.connect(sandbox.sandboxId) +} catch (err) { + await sandbox.kill(); + throw err; +} +``` + + + +## Nächste Schritte + +- **[SDK-Referenz](/sandboxes/sdk-reference)** — jede Methode von `Sandbox`, `CodeSandbox` und `Volume`. +- **[Code Interpreter](/sandboxes/code-interpreter)** — zustandsbehafteten, mehrsprachigen Code ausführen. +- **[Persistent Volumes](/sandboxes/volumes)** — Speicher anhängen, der länger als eine einzelne Sandbox bestehen bleibt. diff --git a/_locales/de/sandboxes/sdk-reference.mdx b/_locales/de/sandboxes/sdk-reference.mdx new file mode 100644 index 0000000..bfa09a0 --- /dev/null +++ b/_locales/de/sandboxes/sdk-reference.mdx @@ -0,0 +1,144 @@ +--- +description: "Jede Klasse und Methode im Lizard SDK für JavaScript und Python: Lizard, Sandbox, CodeSandbox und Volume, mit Optionen und Rückgabetypen." +--- + + + +# SDK-Referenz + +Die Pakete `@lizard-build/sdk` (JS/TS) und `lizard-sdk` (Python) werden von den meisten Agents, Apps und Skripten verwendet, um Sandboxes zu steuern. Diese Seite erfasst jede Klasse und Methode; eine Einführung finden Sie im [Quickstart](/sandboxes/quickstart). + + + +## Installieren & authentifizieren + +```bash +npm install @lizard-build/sdk # JavaScript / TypeScript +pip install lizard-sdk # Python +``` + +Das SDK liest `LIZARD_API_KEY` aus der Umgebung oder akzeptiert eine explizite Option `apiKey` für `Sandbox.create` / `Sandbox.connect`. Wie Sie einen Schlüssel erstellen, finden Sie unter [Quickstart → Authentifizieren](/sandboxes/quickstart#authenticate). + +Jede Sandbox gehört außerdem zu einem **Projekt** — die Nutzung wird pro Projekt abgerechnet, daher wird eine Erstellung ohne Projekt abgelehnt. + +## `Lizard` + +Ein Client, der an ein Projekt gebunden ist, sodass Sie das Projekt einmal angeben statt bei jedem Aufruf. + +| Mitglied | Beschreibung | +|---|---| +| `new Lizard({ project, apiKey?, apiUrl?, timeoutMs? })` | Einen Client erstellen. `project` ist erforderlich — seine ID, sein Slug oder sein Name (`Lizard(project=…)` in Python). | +| `lizard.create(template?, options?)` | Eine Sandbox im Projekt des Clients starten. | +| `lizard.connect(sandboxId)` | Eine Sandbox per ID anbinden und sie automatisch fortsetzen, wenn sie pausiert ist. | +| `lizard.list()` | Alle laufenden Sandboxes für das Konto auflisten. | +| `lizard.projectId()` | Die Projektreferenz des Clients in ihre ID auflösen (nach dem ersten Aufruf zwischengespeichert). | + +```ts +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +Eine Projektreferenz, die zu nichts passt, auf das der Schlüssel zugreifen kann, löst vor dem Start irgendeiner Sandbox einen Fehler aus und listet die Projekte auf, die er sehen kann. + +> Python-Methodennamen mit einem nachgestellten Unterstrich (`exec_`) vermeiden Kollisionen mit reservierten Wörtern, und Eigenschaften verwenden snake_case (`sandbox_id`) statt camelCase (`sandboxId`). Die folgenden Beispiele verwenden JS/TS-Namen; prüfen Sie das installierte Python-Paket für Methodensignaturen. + +## `Sandbox` + +| Mitglied | Beschreibung | +|---|---| +| `Sandbox.create(template?, options?)` | Eine Sandbox starten. `template` ist standardmäßig `'base'`; `options.project` benennt das Projekt, dem die Kosten berechnet werden. | +| `Sandbox.connect(sandboxId)` | Eine Sandbox per ID anbinden und sie automatisch fortsetzen, wenn sie pausiert ist. | +| `Sandbox.list()` | Alle laufenden Sandboxes für das Konto auflisten. | +| `sandbox.sandboxId` | Die ID der Sandbox (`sandbox_id` in Python). | +| `sandbox.process.exec(cmd)` | Einen Befehl ausführen und auf seinen Abschluss warten (`process.exec_` in Python). Gibt `{ stdout, stderr, exitCode }` zurück. | +| `sandbox.fs.write(path, data)` | Eine Datei schreiben — String oder Bytes; erstellt übergeordnete Verzeichnisse. | +| `sandbox.fs.read(path)` | Eine Datei als UTF-8-String lesen. | +| `sandbox.fs.list(path)` | Verzeichniseinträge auflisten → `[{ name, path, type, size }]`. | +| `sandbox.fs.makeDir(path)` | Ein Verzeichnis und alle fehlenden übergeordneten Verzeichnisse erstellen. | +| `sandbox.fs.remove(path)` | Eine Datei oder ein Verzeichnis löschen. | +| `sandbox.getHost(port)` | Eine Route zu `port` registrieren und ihren öffentlichen, TLS-terminierten Hostnamen zurückgeben. | +| `sandbox.pause()` | Guest-vCPUs stoppen und den Zustand im Host-Speicher behalten. Lesen Sie den [Lebenszyklus-Status](#lifecycle-status), bevor Sie sich auf eine Pause über die ursprüngliche Frist hinaus verlassen. | +| `sandbox.resume()` | Eine pausierte Sandbox an Ort und Stelle fortsetzen. | +| `sandbox.setTimeout(ms)` | Die verbleibende Lebensdauer einer laufenden Sandbox in Millisekunden setzen (mindestens 1000). | +| `sandbox.getInfo()` | Metadaten abrufen → `{ sandboxId, template, startedAt, endAt, … }`. | +| `sandbox.kill()` | Die Sandbox sofort beenden und ihre Ressourcen freigeben. | + +### `Sandbox.create(template?, options?)` + +| Option | Typ | Standard | Hinweise | +|---|---|---|---| +| `template` | string | `'base'` | `'base'` oder `'code-interpreter-v1'` — die beiden unterstützten [Vorlagen](/sandboxes#templates) | +| `project` | string | — | **Erforderlich.** Das Projekt, dem die Kosten berechnet werden — seine ID, sein Slug oder sein Name (`project` in Python). Nicht nötig über einen Client `Lizard`. | +| `projectId` | string | — | Exakte Projekt-ID; überspringt das Auflösen von `project` | +| `timeoutMs` | int | SDK-Standard 5 min | Lebensdauer in ms | +| `region` | string | auto | An eine Region anheften | +| `volumeId` | string | — | Ein [Volume](/sandboxes/volumes) bei `/data` anhängen | +| `apiKey` | string | `LIZARD_API_KEY` env var | Expliziter API-Schlüssel, überschreibt die Umgebung | + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); +``` + +## `CodeSandbox` + +Erweitert `Sandbox` um einen zustandsbehafteten Kernel. Die vollständige Einführung finden Sie unter [Code Interpreter](/sandboxes/code-interpreter). + +| Mitglied | Beschreibung | +|---|---| +| `CodeSandbox.create(options?)` | Einen Code-Interpreter starten (standardmäßig mit der Vorlage `code-interpreter-v1`). Akzeptiert dieselbe Option `project` wie `Sandbox.create`. | +| `CodeSandbox.connect(sandboxId)` | Einen vorhandenen Code-Interpreter-Sandbox anbinden (und automatisch fortsetzen). | +| `sandbox.runCode(code, opts?)` | Code im Kernel ausführen. Gibt ein `Execution` zurück. | +| `sandbox.createContext(opts)` | Einen isolierten Namespace erstellen — `{ language }`. | +| `sandbox.listContexts()` | Die Kontexte der Sandbox auflisten. | +| `sandbox.restartContext(context)` | Alle Variablen bzw. den gesamten Zustand in einem Kontext löschen. | +| `sandbox.deleteContext(context)` | Die Ressourcen eines Kontexts freigeben. | + +### `runCode(code, opts?)` + +| Option | Beschreibung | +|---|---| +| `language` | Laufzeit für einen einmaligen Aufruf — `'python'` (Standard), `'javascript'` oder `'bash'`. Gegenseitig ausschließend mit `context`. | +| `context` | Innerhalb eines bestimmten isolierten Kontexts statt des Standardkontexts ausführen. Gegenseitig ausschließend mit `language`. | +| `onStdout` / `onStderr` | Ausgabe zeilenweise streamen, während sie erzeugt wird. | +| `onResult` | Wird für jedes Rich Ergebnis aufgerufen (Werte, erzeugte Bilder/Diagramme). | +| `onError` | Wird mit einem `ExecutionError` aufgerufen, wenn der Code eine Ausnahme auslöst. | + +Gibt ein `Execution` zurück: + +| Feld | Beschreibung | +|---|---| +| `stdout` / `stderr` | Erfasste Ausgabeströme | +| `results` | Rich Results (Werte sowie eventuell erzeugte Bilder / Diagramme) | +| `error` | Ein `ExecutionError` (`name`, `message`, `traceback`), wenn der Code eine Ausnahme ausgelöst hat | +| `executionCount` | Monotoner Zähler für den Kernel | + +## `Volume` + +Die vollständige Einführung finden Sie unter [Persistent Volumes](/sandboxes/volumes). + +| Mitglied | Beschreibung | +|---|---| +| `Volume.create(projectId, name, options)` | Ein Volume erstellen. `options.sizeGb` ist standardmäßig `5`. | +| `Volume.list(projectId)` | Volumes in einem Projekt auflisten → `[{ id, name, sizeGb, status, attachedTo, … }]`. | +| `Volume.get(projectId, volumeId)` | Einen Handle für ein vorhandenes Volume abrufen. | +| `volume.getInfo(projectId)` | Metadaten und Anhangsstatus abrufen. | +| `volume.delete(projectId)` | Ein Volume löschen — es muss zuvor getrennt werden. | + + + +## Siehe auch + +- [Quickstart](/sandboxes/quickstart) — installieren, authentifizieren und eine vollständige Einführung. +- [Code Interpreter](/sandboxes/code-interpreter) — der Leitfaden zu `CodeSandbox`. +- [Persistent Volumes](/sandboxes/volumes) — der Leitfaden zu `Volume`. + + + +## Lebenszyklus-Status + +Bevor Sie sich darauf verlassen, dass eine Pause eine Sitzung über ihre ursprüngliche Frist hinaus erhält, lesen Sie die [bekannten Probleme](/platform/known-issues#sandbox-pause-and-expiration). Eine Pause hält den Guest-Zustand im Host-Speicher; sie ist kein dauerhaftes Backup. diff --git a/_locales/de/sandboxes/volumes.mdx b/_locales/de/sandboxes/volumes.mdx new file mode 100644 index 0000000..44436d3 --- /dev/null +++ b/_locales/de/sandboxes/volumes.mdx @@ -0,0 +1,79 @@ +--- +description: "Hänge ein Volume unter /data ein, um Checkpoints, Weights oder ein Arbeitsverzeichnis über Sandbox-Neustarts hinweg zu behalten. Volumes erstellen, einhängen und verwalten." +--- + +# Persistent Volumes + +Sandboxes sind flüchtig — wenn eine beendet wird oder abläuft, ist ihr Dateisystem weg. Ein **Volume** ist persistenter Blockspeicher, der länger lebt als jede einzelne Sandbox. Hänge eines ein, um Daten (Checkpoints, Modellgewichte, ein Arbeitsverzeichnis) über Sandbox-Neustarts hinweg zu behalten. + +Ein Volume kann **jeweils nur an eine Sandbox gleichzeitig** angehängt werden und wird innerhalb der Micro-VM unter **`/data`** eingehängt. Da ein Volume an den Node gebunden ist, auf dem es liegt, wird eine Sandbox, die es einhängt, auf genau diesem Node geplant. + + + +## Erstellen und einhängen + +Hänge ein Volume ein, indem du seine ID an `Sandbox.create` übergibst, zusammen mit dem Projekt, dem die Sandbox in Rechnung gestellt wird. Alles, was unter `/data` geschrieben wird, bleibt erhalten, nachdem die Sandbox verschwunden ist. + +```ts +import { Sandbox, Volume } from '@lizard-build/sdk'; + +// Create a 10 GB volume in a project (default size: 5 GB) +const volume = await Volume.create('proj_123', 'agent-workdir', { sizeGb: 10 }); + +// Attach it to a sandbox — mounted at /data +const sandbox = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + await sandbox.fs.write('/data/state.json', JSON.stringify({ step: 1 })); +} finally { + await sandbox.kill(); // the volume persists +} + +// A later sandbox re-attaches and sees the data +const next = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + console.log(await next.fs.read('/data/state.json')); // {"step":1} +} finally { + await next.kill(); +} +``` + + + +## Volumes verwalten + +```ts +await Volume.list('proj_123'); // [{ id, name, sizeGb, status, attachedTo, … }] +const v = await Volume.get('proj_123', 'vol_abc'); +await v.getInfo('proj_123'); +await v.delete('proj_123'); // must be detached first +``` + +| Methode | Beschreibung | +|---|---| +| `Volume.create(projectId, name, { sizeGb })` | Ein Volume erstellen (standardmäßig 5 GB) | +| `Volume.list(projectId)` | Volumes in einem Projekt auflisten | +| `Volume.get(projectId, volumeId)` | Ein Handle für ein vorhandenes Volume abrufen | +| `volume.getInfo(projectId)` | Metadaten und Anhangsstatus abrufen | +| `volume.delete(projectId)` | Ein Volume löschen (muss ausgehängt sein) | + + + +## Im Dashboard + +Volumes befinden sich im Tab **Sandboxes → Volumes** eines Projekts. Erstelle eines mit Name und Größe; die Tabelle zeigt für jedes Volume Größe, Status (`available` / `attached`) und welche Sandbox es hält. Ein Volume wird automatisch wieder auf `available` freigegeben, wenn seine Sandbox beendet wird oder abläuft. Siehe die Anleitung zum [Dashboard](/sandboxes/dashboard). + + + +## Hinweise + +- Ein Volume kann jeweils nur an **eine Sandbox** gleichzeitig angehängt werden. Der Versuch, ein bereits angehängtes Volume einzuhängen, führt zu einem Konflikt. +- Das Löschen einer Sandbox (oder ihr Ablauf) **trennt** das Volume — es löscht es nicht. Die Daten bleiben für die nächste Einhängung erhalten. +- Lösche das Volume selbst, um den Speicherplatz freizugeben. +- Eine pausierte Sandbox behält ihre Einhängung weiterhin. Persistent Volumes verwenden Node-lokalen Speicher; exportiere Daten, die du nach einem Node-Ausfall wiederherstellen können musst. Siehe [Speicher und Wiederherstellung](/platform/storage-and-recovery). + + + +## Siehe auch + +- [SDK Reference](/sandboxes/sdk-reference) — jede `Volume`-Methode. +- [Quickstart](/sandboxes/quickstart) — ein Volume beim Erstellen der Sandbox einhängen. diff --git a/_locales/de/studio/_meta.ts b/_locales/de/studio/_meta.ts new file mode 100644 index 0000000..2524ce0 --- /dev/null +++ b/_locales/de/studio/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'getting-started': "Lizard Studio installieren", +}; diff --git a/_locales/de/studio/getting-started.mdx b/_locales/de/studio/getting-started.mdx new file mode 100644 index 0000000..ff13703 --- /dev/null +++ b/_locales/de/studio/getting-started.mdx @@ -0,0 +1,145 @@ +--- +title: "Lizard Studio für Claude Code und ChatGPT installieren" +description: "Installieren Sie Lizard Studio in Chrome, verbinden Sie Claude Code oder ChatGPT mit einem lokalen Projekt und führen Sie Ihre erste Website-Änderung durch. Folgen Sie der Einrichtungsanleitung." +--- + + + +# Lizard Studio installieren + +Lizard Studio ist eine kostenlose Chrome-Erweiterung, die Claude Code oder ChatGPT mit der Seite verbindet, die Sie gerade erstellen. Öffnen Sie einen Chat neben der Seite, wählen Sie ein Element aus und bitten Sie den Agenten, die Dateien in Ihrem lokalen Projekt zu bearbeiten. Die Erweiterung enthält Seiteninspektion, Anmerkungen, Lineale, eine Farbpipette und Browser-Debugging-Tools. + +Diese Anleitung führt Sie von der Installation bis zu einer Quellcodeänderung, die ein Neuladen der Seite übersteht. Ein Beispiel zum Herunterladen finden Sie im [visuellen Bearbeitungsleitfaden für Claude Code](https://lizard.build/blog/claude-code-visual-editor). + + + +## Das benötigen Sie + +- Google Chrome auf macOS, Windows oder Linux. +- Node.js und npm. Der lokale Host setzt Node.js 18 oder höher voraus; Ihr gewählter Agent kann eine höhere Anforderung haben. Verwenden Sie eine Node.js-Version, die beide unterstützen. +- Die lokale CLI für Claude Code oder ChatGPT, angemeldet mit Ihrem eigenen Konto. +- Einen lokalen Projektordner. Damit Quellcodeänderungen im Browser sichtbar werden, starten Sie den Entwicklungsserver dieses Projekts und öffnen dessen URL. + +Die Erweiterung und der Host sind kostenlos und unter der MIT-Lizenz veröffentlicht. Die Nutzung des Modells unterliegt den Kontoanforderungen, Limits und Gebühren Ihres Anbieters. Sie benötigen kein Lizard-Konto, um Lizard Studio zu verwenden. + + + +## 1. Die Chrome-Erweiterung hinzufügen + +Öffnen Sie [Lizard Studio im Chrome Web Store](https://chromewebstore.google.com/detail/kgbaeoalmkabpoglpjcdmppdmcipfdeh) und wählen Sie **Zu Chrome hinzufügen**. Heften Sie die Erweiterung an, wenn Sie sie über die Symbolleiste erreichen möchten. + +Die Symbolleiste stellt die Design-Tools bereit; das Seitenpanel von Chrome enthält Ihre Chats. Die Installation aus dem Store erfordert keinen Entwicklermodus. + + + +## 2. Ihren Agenten installieren + +Wählen Sie den Agenten, den Sie verwenden möchten. Den anderen können Sie später hinzufügen. + +Für Claude Code folgen Sie der [offiziellen Einrichtungsanleitung](https://code.claude.com/docs/en/setup). Prüfen Sie die Installation in einem Terminal: + +```bash +claude --version +``` + +Für ChatGPT in Lizard Studio installieren Sie die Codex CLI: + +```bash +npm install -g @openai/codex +codex --version +``` + +Lizard Studio bezeichnet diesen Agenten in der Benutzeroberfläche als **ChatGPT**. Das Paket und der Terminalbefehl verwenden den Namen **Codex**. Dies ist ein lokaler Coding-Agent, der mit Ihrem Projekt verbunden ist; die Website chatgpt.com wird dabei nicht eingebettet. + +Öffnen Sie den gewählten Agenten und schließen Sie dessen Anmeldeablauf ab, bevor Sie fortfahren. Unterstützte Verbindungswege finden Sie im [Lizard Studio README](https://github.com/lizard-build/lizard-studio#setup). + + + +## 3. Den lokalen Host installieren + +Führen Sie diesen Befehl einmal in einem Terminal aus: + +```bash +npx @lizard-build/lizard-studio-host install +``` + +Der Host verbindet die Chrome-Erweiterung mit dem Agenten auf Ihrem Computer. Das Installationsprogramm kopiert den Host nach `~/.lizard-studio/host` und registriert ihn beim Browser. Lassen Sie Node.js installiert: Der Browser verwendet es, um den Host zu starten. + +Öffnen Sie das Seitenpanel der Erweiterung nach der Installation erneut. Wenn Sie einen vorhandenen Host aktualisiert haben, öffnen Sie das Panel erneut, bevor Sie einen neuen Chat starten. + + + +## 4. Die Seite mit ihrem Projekt verbinden + +Starten Sie den Entwicklungsserver Ihres Projekts mit dem üblichen Befehl. Öffnen Sie die ausgegebene URL in Chrome und öffnen Sie dann Lizard Studio auf diesem Tab. + +Starten Sie einen Chat, wählen Sie **Claude Code** oder **ChatGPT** und wählen Sie den Ordner, der den Quellcode dieses Projekts enthält. Jeder Chat behält seinen eigenen Projektordner und seine eigenen Berechtigungen. Ein Tab mit der richtigen Seite teilt dem Agenten nicht automatisch mit, welches lokale Repository geändert werden soll. + +Bevor Sie um eine Bearbeitung bitten, prüfen Sie die Verbindung mit einer schreibgeschützten Anfrage: + +```text +Read this page's title and inspect its main heading. Tell me which +local project folder you are using. Do not change any files yet. +``` + +Wenn der Agent den falschen Ordner nennt, korrigieren Sie die Auswahl, bevor Sie fortfahren. + + + +## 5. Ein Element auswählen und eine Änderung vornehmen + +Wählen Sie **Selector** in der Seiten-Symbolleiste und klicken Sie auf das Element, das Sie ändern möchten. Die Auswahl fügt dem Chat Kontext hinzu. Bei einem visuellen Problem, das mehrere Elemente betrifft, verwenden Sie **Annotate**, um den Bereich zu markieren und den Screenshot dem Chat hinzuzufügen. + +Probieren Sie eine Anfrage mit messbarem Ergebnis aus: + +```text +Find the source for the selected card's action row. Set the gap +between its buttons to 24px in the project files. Keep the button +labels and colors unchanged. Show the diff, then inspect the +rendered row to check its computed gap. +``` + +Lesen Sie die vorgeschlagenen Dateiänderungen und verwenden Sie die Berechtigungssteuerung, um die gewünschte Arbeit zu genehmigen. Ihr Berechtigungsmodus bestimmt, welche Aktionen eine separate Aufforderung benötigen. + +Wenn Ihr Entwicklungsserver die Seite neu lädt, prüfen Sie das Ergebnis. Falls sie nicht automatisch neu lädt, aktualisieren Sie Chrome. + + + +## 6. Prüfen, dass die Änderung bestehen bleibt + +Eine temporäre DOM-Änderung kann korrekt aussehen, bis Sie die Seite aktualisieren. Eine Quellcodeänderung ändert die Dateien, die Ihr Entwicklungsserver ausliefert. + +Prüfen Sie den Datei-Diff in Ihrem Editor oder führen Sie `git diff` im Projektordner aus. Aktualisieren Sie die Seite und prüfen Sie dasselbe Element erneut. Im obigen Beispiel sollte der berechnete Abstand weiterhin `24px` sein. Prüfen Sie sowohl Desktop- als auch schmale Layouts, bevor Sie die Änderung beibehalten. + +Das Bearbeiten eines lokalen Projekts aktualisiert keine bereitgestellte Website. Stellen Sie separat bereit, wenn die Änderung live gehen soll. + + + +## Wenn die Verbindung fehlschlägt + +| Was Sie sehen | Was Sie prüfen sollten | +|---|---| +| Das Seitenpanel kann den Host nicht erreichen | Führen Sie das Host-Installationsprogramm aus, prüfen Sie, ob Node.js verfügbar ist, und öffnen Sie dann das Panel erneut. | +| Der Agent kann nicht starten | Prüfen Sie `claude --version` oder `codex --version` in einem Terminal und schließen Sie die Anmeldung dieses Agenten ab. | +| Der Agent sieht die Seite, kann aber ihren Code nicht finden | Wählen Sie den richtigen lokalen Ordner und prüfen Sie, ob der Tab den Entwicklungsserver dieses Projekts verwendet. | +| Eine Änderung verschwindet nach dem Aktualisieren | Prüfen Sie den Diff. Bitten Sie um eine Quellcodeänderung, wenn der Agent nur das Live-DOM geändert hat. | +| Die Symbolleiste erscheint nicht auf einer Chrome-Einstellungsseite | Chrome blockiert Content-Scripts auf Seiten unter `chrome://`, auf der Seite "Neuer Tab" und im Chrome Web Store. Öffnen Sie eine normale Website. | + +Unter macOS vermeidet der Host-Speicherort in `~/.lizard-studio/host` außerdem Einschränkungen, auf die Chrome stoßen kann, wenn ein Host unter Desktop, Dokumente oder Downloads gestartet wird. Weitere Details finden Sie in den [Host-Hinweisen im README](https://github.com/lizard-build/lizard-studio#2-the-local-host-one-time). + + + +## Wohin Ihre Daten gehen + +Die Erweiterung und der Host laufen auf Ihrem Computer. Der ausgewählte Modellanbieter erhält die Anfragen, die Sie über seinen Agenten senden. Lizard Studio verwendet keinen Lizard-Chatserver und sammelt keine Telemetrie. Eine lokale Installation bedeutet nicht, dass ein Cloud-Modell Ihre Prompts lokal verarbeitet. Lesen Sie die [Datenschutzerklärung von Lizard Studio](https://github.com/lizard-build/lizard-studio/blob/main/PRIVACY.md), bevor Sie es mit einem Projekt verwenden, das Datenbeschränkungen hat. + + + +## Verwandte Anleitungen + +- [Ein Element auswählen und sein CSS korrigieren](https://lizard.build/blog/claude-code-visual-editor) +- [ChatGPT zum Bearbeiten einer lokalen Website verwenden](https://lizard.build/studio/chatgpt) +- [Lizard Studio und Claude in Chrome vergleichen](https://lizard.build/studio/compare/claude-in-chrome) +- [Eine Claude Code-GUI auswählen](https://lizard.build/blog/claude-code-gui) + +Einrichtung anhand des Lizard Studio-Quellcodes am 14. September 2026 geprüft. diff --git a/_locales/de/variables/_meta.ts b/_locales/de/variables/_meta.ts new file mode 100644 index 0000000..83ae951 --- /dev/null +++ b/_locales/de/variables/_meta.ts @@ -0,0 +1,5 @@ +export default { + index: "Variablen & Secrets", + references: "Dienstübergreifende Referenzen", + troubleshooting: "Fehlerbehebung", +}; diff --git a/_locales/de/variables/index.mdx b/_locales/de/variables/index.mdx new file mode 100644 index 0000000..30c7040 --- /dev/null +++ b/_locales/de/variables/index.mdx @@ -0,0 +1,112 @@ +--- +description: "Legen Sie Secrets auf Service- oder Projektebene fest, verstehen Sie die Merge-Priorität und sehen Sie, welche Werte einen Build versus den laufenden Container erreichen." +--- + + + +# Variablen & Secrets + +Lizard speichert Konfiguration als **Secrets**. Sie gibt es in zwei Bereichen — **Service** (der Standard) und **Projekt** (`--global`) — und sie werden in einer festgelegten Prioritätsreihenfolge in die Umgebung Ihrer App zusammengeführt. Es gibt keinen globalen Bereich auf Workspace-Ebene. + + + +## Variablen setzen + +`lizard secrets set` ist variadisch — Sie können eine oder mehrere auf einmal setzen. Standardmäßig schreibt es in den **verknüpften Service**: + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + +Fügen Sie `--global` hinzu, um in den Bereich **Projekt** zu schreiben (jeder Service im Projekt sieht ihn): + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +## Auflisten, löschen, importieren + +```bash +lizard secrets list # current scope +lizard secrets list --show # reveal values +lizard secrets delete OLD_KEY ANOTHER_KEY # variadic +cat .env | lizard secrets import # import dotenv from stdin +``` + +Im [Befehlsreferenz für `lizard secrets`](/cli/secrets) finden Sie alle Flags. + + + +## Geltungsbereich + +| Gültigkeitsbereich | Befehl | Gespeichert als | Sichtbar für | +|-------|---------|-----------|------------| +| **Service** (default) | `lizard secrets set K=v --service ` | `secrets.services[]` | nur dieser Service | +| **Projekt** (global) | `lizard secrets set K=v --global` | `secrets.shared` | jeder Service im Projekt | + +**Verwenden Sie standardmäßig den Service-Bereich.** Ein kompromittierter Service kann seine eigene Umgebung lesen — ein breiterer Bereich bedeutet, dass ohne Grund mehr Anmeldedaten offengelegt werden. Reservieren Sie `--global` für nicht geheime, nachweislich öffentliche Werte wie `LOG_LEVEL`, `NODE_ENV`, Feature-Flags oder ein Frontend-`SENTRY_DSN`. Wenn Sie unsicher sind, ob ein Wert ein Secret ist, behandeln Sie ihn als solches und begrenzen Sie ihn auf den Service. + +Für gemeinsam genutzte Ressourcen wie eine Datenbank gilt: Legen Sie die DSN **nicht** in `--global` ab — binden Sie sie pro Consumer mit einer [Referenz](/variables/references): + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service worker +``` + +Die Rotation erfolgt weiterhin einmal auf dem Add-on; jede Referenz wird aktualisiert. + + + +## Priorität + +Wenn derselbe Schlüssel an mehreren Stellen definiert ist, gilt: **Der letzte Schreibvorgang gewinnt**: + +``` +addon-issued env < project secrets < project env < app env < app secrets < platform vars +``` + +Also **überschreiben App-Secrets Projekt-Secrets**, und **Plattformvariablen** (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) werden zuletzt angewendet und können nicht überschrieben werden. + + + +## Build-Zeit vs. Laufzeit + +Die meisten Variablenänderungen werden **ohne Rebuild** angewendet — der Service wird neu gestartet, um sie zu übernehmen, was ein paar Sekunden dauert. Ausnahmen sind Build-Zeit-Werte, die in das Image eingebettet werden: + +- Änderungen an `VITE_*` und `NEXT_PUBLIC_*` **erzwingen beim nächsten Bereitstellen einen Rebuild**. + +Siehe [Build-Pipeline → Rebuild-Trigger](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Überprüfen + +Bestätigen Sie, was ein laufender Service tatsächlich sieht: + +```bash +lizard ssh --service api -- env +``` + +Wenn ein erwarteter Wert nicht vorhanden ist, siehe [Fehlerbehebung → ein Secret oder eine Referenz wird nicht angezeigt](/variables/troubleshooting/reference-not-applied). + + + +## Lokale Entwicklung + +Führen Sie einen Befehl **lokal** aus, wobei die Projekt- und Service-Secrets des Service eingefügt werden (praktisch für Skripte und Migrationen): + +```bash +lizard run --service api -- node scripts/seed.js +``` + +Siehe [`lizard run` vs. `lizard ssh`](/cli/run#run-vs-ssh). + + + +## Siehe auch + +- [Service-übergreifende Referenzen](/variables/references) — lesen Sie die Werte eines Service aus einem anderen, ohne Anmeldedaten per Copy-paste zu duplizieren. +- [`lizard secrets`](/cli/secrets) — die vollständige Befehlsreferenz. diff --git a/_locales/de/variables/references.mdx b/_locales/de/variables/references.mdx new file mode 100644 index 0000000..4a5dfbb --- /dev/null +++ b/_locales/de/variables/references.mdx @@ -0,0 +1,76 @@ +--- +description: "Lies die Werte eines Dienstes oder Add-ons aus einem anderen mit der Syntax ${{name.KEY}}. Wie Referenzen beim Bereitstellen aufgelöst werden und warum sie besser sind als Kopieren." +--- + + + +# Dienstübergreifende Referenzen + +Mit Referenzen kann ein Dienst oder Add-on die Werte eines anderen lesen, ohne Credentials per Copy-and-paste zu duplizieren. Sie halten Secrets an einer Stelle und rotieren automatisch. + +## Syntax + +``` +${{.}} +``` + +- `` — der Name des Zieldienstes oder Add-ons (der im Dashboard angezeigt und in `lizard add -n` verwendet wird). +- `` — ein Schlüssel in der zusammengeführten Umgebung des Ziels. + +Verwende sie überall dort, wo ein Wert akzeptiert wird — am häufigsten in einem Secret: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + + + +## Wie sie aufgelöst werden + +- Referenzen werden zur **Deploy-Zeit** anhand der zusammengeführten Umgebung des Ziels aufgelöst. +- Sie werden per **ID** gespeichert, daher macht ein späteres Umbenennen des Ziels die Referenz nicht kaputt. +- Eine Referenz auf ein **fehlendes** Ziel oder einen fehlenden Schlüssel wird zu einem **leeren String** aufgelöst — das Bereitstellen schlägt dadurch *nicht* fehl. +- Nur **zirkuläre** Referenzen werfen einen Fehler. + +> Weil ein fehlender Schlüssel stillschweigend leer wird, prüfe nach dem Einrichten einer Referenz immer, ob der Consumer den Wert tatsächlich erhalten hat: +> ```bash +> lizard ssh --service api -- env | grep DATABASE_URL +> ``` + +Wenn eine Referenz nicht wie erwartet erscheint, siehe [Troubleshooting → ein Secret oder eine Referenz wird nicht angezeigt](/variables/troubleshooting/reference-not-applied). + + + +## Häufige Muster + +**Ein Add-on mit mehreren Diensten verbinden** — auf jedem Consumer binden, damit die Rotation überall weitergegeben wird: + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +``` + +**Einen Wert aus einem anderen Dienst referenzieren** — z. B. eine berechnete URL oder ein Token teilen: + +```bash +lizard secrets set UPSTREAM_URL='${{api.LIZARD_PUBLIC_DOMAIN}}' --service web +``` + +**Ein zweites Add-on desselben Typs referenzieren** — verwende seinen generierten Namen: + +```bash +lizard secrets set CACHE_URL='${{redis-winter-otter.REDIS_URL}}' --service api +``` + + + +## Warum nicht einfach `--global` verwenden? + +Wenn du eine gemeinsame DSN im Projektbereich (`--global`) ablegst, ist sie für *jeden* Dienst sichtbar, auch für solche, die sie nicht benötigen. Referenzen geben dir dieselbe Rotation mit einer Single Source of Truth und sorgen zugleich dafür, dass jedes Secret auf die Dienste beschränkt bleibt, die es tatsächlich verwenden. Siehe [Secret-Scopes](/variables#scoping). + + + +## Siehe auch + +- [Variablen & Secrets](/variables) — Scopes und Priorität. +- [`lizard secrets`](/cli/secrets) — die vollständige Befehlsreferenz. diff --git a/_locales/de/variables/troubleshooting/_meta.ts b/_locales/de/variables/troubleshooting/_meta.ts new file mode 100644 index 0000000..bf33223 --- /dev/null +++ b/_locales/de/variables/troubleshooting/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'reference-not-applied': "Ein Secret oder eine Referenz wird nicht angezeigt", +}; diff --git a/_locales/de/variables/troubleshooting/reference-not-applied.mdx b/_locales/de/variables/troubleshooting/reference-not-applied.mdx new file mode 100644 index 0000000..9b195a6 --- /dev/null +++ b/_locales/de/variables/troubleshooting/reference-not-applied.mdx @@ -0,0 +1,71 @@ +--- +description: "Dein Secret oder Verweis ist gesetzt, aber der Service sieht ihn nie. Fehlende Ziele werden zu leeren Strings aufgelöst, und die Rangfolge kann einen Wert verdecken." +--- + + + +# Ein Secret oder Verweis erscheint nicht in meinem Service + +Du hast ein Secret oder einen `${{name.KEY}}`-Verweis gesetzt, erneut bereitgestellt, und der laufende Service sieht den erwarteten Wert trotzdem nicht. + + + +## Was das bedeutet + +Der von dir gesetzte Wert ist nie in die zusammengeführte Umgebung des Service gelangt — oder etwas anderes in der Zusammenführung hat ihn überschrieben, bevor die App gestartet wurde. + + + +## Warum das passieren kann + +- **Das Verweisziel oder der Schlüssel existiert nicht.** Ein Verweis auf einen fehlenden Service-/Add-on-Namen oder auf einen Schlüssel, den dieses Add-on nicht bereitstellt, wird zu einem **leeren String** aufgelöst, statt das Deployment fehlschlagen zu lassen. Es gibt keinen Fehler als Hinweis — der Service startet einfach mit einem leeren Wert. +- **Etwas mit höherer Priorität hat ihn überschrieben.** Werte werden in einer festen Reihenfolge zusammengeführt — `addon-issued env < project secrets < project env < app env < app secrets < platform vars` — daher kann ein projektbezogenes (`--global`) Secret stillschweigend von einem servicebezogenen Secret mit demselben Schlüssel verdeckt werden, und Plattformvariablen (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) haben immer Vorrang und können überhaupt nicht überschrieben werden. +- **Du hast einen Build-Zeit-Wert geändert, aber keinen neuen Build ausgeführt.** Die meisten Variablenänderungen werden ohne Rebuild übernommen — der Service startet neu, um sie zu übernehmen. `VITE_*`- und `NEXT_PUBLIC_*`-Werte sind die Ausnahme — sie werden in die gebauten Assets eingebettet, daher übernimmt ein einfacher Neustart keinen neuen Wert; der Service braucht einen frischen Build. + + + +## Mögliche Lösungen + + + +### Prüfe, was der laufende Service tatsächlich sieht + +Das ist maßgeblich — es zeigt die Umgebung des Live-Containers, nicht das, von dem du glaubst, dass du es gesetzt hast: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + +Wenn der Schlüssel fehlt oder leer ist, ist das Verweisziel bzw. der Schlüssel falsch, oder für diesen Geltungsbereich ist nichts gesetzt. Prüfe den Add-on- oder Service-Namen mit `lizard ps` noch einmal und den Schlüssel anhand der [dokumentierten Variablen](/addons) des Addons. + + + +### Prüfe auf eine Kollision zwischen Geltungsbereichen + +Liste Secrets in beiden Geltungsbereichen auf und vergleiche sie: + +```bash +lizard secrets list --service api --show +lizard secrets list --global --show +``` + +Denke daran: **App-Secrets überschreiben Projekt-Secrets** — wenn ein servicebezogener Wert für denselben Schlüssel existiert, hat er Vorrang vor allem, was mit `--global` gesetzt wurde. + + + +### Nach einer Änderung zur Build-Zeit neu bauen + +Wenn der geänderte Schlüssel `VITE_*` oder `NEXT_PUBLIC_*` ist, löse einen echten Rebuild statt eines Neustarts aus: + +```bash +lizard redeploy --service api +``` + +Siehe [Build-Zeit vs. Laufzeit](/variables#build-time-vs-runtime) und [Build-Pipeline → was einen Rebuild auslöst](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Siehe auch + +- [Variablen & Secrets](/variables) — Geltungsbereiche und Priorität. +- [Service-übergreifende Verweise](/variables/references) — Verweissyntax und Auflösung. diff --git a/_locales/es/_meta.ts b/_locales/es/_meta.ts new file mode 100644 index 0000000..57d8489 --- /dev/null +++ b/_locales/es/_meta.ts @@ -0,0 +1,18 @@ +export default { + index: "Introducción", + 'getting-started': "Inicio rápido de la app", + studio: "Lizard Studio", + 'framework-guides': "Guías de frameworks", + guides: "Guías", + platform: "Límites y operaciones", + concepts: "Conceptos básicos", + deploy: "Despliegue", + variables: "Variables", + networking: "Redes", + addons: "Addons gestionados", + sandboxes: "Sandboxes", + observability: "Observabilidad", + cli: "Referencia de CLI", + dashboard: "Panel de la app", + agents: "Agentes de código", +}; diff --git a/_locales/es/addons/_meta.ts b/_locales/es/addons/_meta.ts new file mode 100644 index 0000000..c3a9a6b --- /dev/null +++ b/_locales/es/addons/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Resumen", + postgres: "Postgres", + redis: "Redis", + storage: "Almacenamiento de objetos (S3)", +}; diff --git a/_locales/es/addons/index.mdx b/_locales/es/addons/index.mdx new file mode 100644 index 0000000..dbe129d --- /dev/null +++ b/_locales/es/addons/index.mdx @@ -0,0 +1,80 @@ +--- +description: "Aprovisiona Postgres, Redis y almacenamiento compatible con S3 gestionados con un solo comando lizard add, y luego conéctalos a los servicios por referencia." +--- + + + +# Addons gestionados + +Lizard aprovisiona **Postgres**, **Redis** y **almacenamiento de objetos compatible con S3** gestionados con un solo comando. Cada addon vive en tu proyecto, expone un conjunto fijo de variables de entorno y lo consumen tus servicios mediante [referencias](/concepts/architecture#cross-resource-references). + + + +## Aprovisionar un addon + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +## Nombres + +El **primer** addon de un tipo determinado recibe el tipo sin más como nombre; así que `${{postgres.DATABASE_URL}}` funciona de inmediato. Los addons adicionales del mismo tipo reciben un nombre generado como `postgres-autumn-bear`. + +No hay fallback de alias de tipo: una referencia debe usar el nombre **real** del addon. Como las referencias se almacenan por ID, puedes cambiar el nombre de un addon después sin romper los consumidores existentes: + +```bash +lizard service rename --service postgres # addons rename through the same command +``` + + + +## Consumir un addon + +Haz referencia a las variables de un addon desde cualquier servicio. La referencia se resuelve en el momento del deploy y rota automáticamente cuando cambian las credenciales del addon: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +Limita la referencia a los servicios que realmente la usan (consulta [Alcance de secretos](/variables#scoping)). + + + +## Variables por tipo + +| Complemento | Variables | +|-------|-----------| +| **postgres** | `DATABASE_URL`, `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`, `POSTGRES_USER`, `POSTGRES_DB`, `POSTGRES_PASSWORD` | +| **redis** | `REDIS_URL` | +| **s3** | `S3_ENDPOINT`, `S3_DEFAULT_BUCKET`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `S3_REGION` | + + + +## Navegadores del panel + +El [panel](/dashboard) incluye un navegador de datos para cada addon: un editor SQL/de tablas para Postgres, un navegador de claves para Redis y un navegador de buckets/objetos para S3, para que puedas inspeccionar y editar datos sin salir de Lizard. + + + +## Almacenamiento + +Los volúmenes de datos de los addons son **solo ampliables**. Aumenta la capacidad con: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Guías por tipo + +- [Postgres](/addons/postgres) +- [Redis](/addons/redis) +- [Almacenamiento de objetos (S3)](/addons/storage) + +Para saber por qué un prototipo normalmente necesita los tres a la vez, consulta [el resto del stack que necesita un SaaS](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#the-rest-of-the-stack-a-saas-needs). diff --git a/_locales/es/addons/postgres.mdx b/_locales/es/addons/postgres.mdx new file mode 100644 index 0000000..6befa67 --- /dev/null +++ b/_locales/es/addons/postgres.mdx @@ -0,0 +1,107 @@ +--- +description: "Aprovisiona una base de datos PostgreSQL gestionada en Lizard, conéctala a un servicio por referencia, ejecuta migraciones al desplegar y amplía su almacenamiento." +--- + +# Managed Postgres + +Una base de datos PostgreSQL gestionada, aprovisionada con un solo comando y conectada a tus servicios por referencia. + + + +## Aprovisionar + +```bash +lizard add postgres +``` + +El primer addon de Postgres se llama `postgres`, así que `${{postgres.DATABASE_URL}}` funciona de inmediato. + + + +## Variables de entorno + +El addon expone un conjunto estándar de variables de conexión: + +| Variable | Descripción | +|----------|-------------| +| `DATABASE_URL` | Cadena de conexión completa (`postgres://…`) | +| `PGHOST` | Host | +| `PGPORT` | Puerto | +| `PGUSER` | Usuario | +| `PGPASSWORD` | Contraseña | +| `PGDATABASE` | Nombre de la base de datos | +| `POSTGRES_USER` | Alias del usuario | +| `POSTGRES_DB` | Alias de la base de datos | +| `POSTGRES_PASSWORD` | Alias de la contraseña | + + + +## Conectar un servicio + +Haz referencia a la cadena de conexión desde el servicio consumidor y vuelve a desplegar: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +La referencia se resuelve en el momento del despliegue y rota automáticamente si cambian las credenciales del addon: cada consumidor obtiene el nuevo valor en su siguiente despliegue. + +Verifica la conectividad sin imprimir la cadena de conexión: + +```bash +lizard run --service api -- sh -c 'psql "$DATABASE_URL" -c "SELECT 1"' +``` + + + +## Ejecutar migraciones al desplegar + +Usa un comando previo al despliegue para las migraciones. Haz que las migraciones se puedan reintentar de forma segura y que sean compatibles tanto con la versión antigua como con la nueva de la aplicación: + +```bash +lizard service set api --set preDeployCommand="npm run migrate" +lizard redeploy --service api +``` + +Para una app de Django, el comando es `python manage.py migrate`; [hosting de apps Python](https://lizard.build/blog/python-app-hosting#deploying-django) tiene el equivalente para Flask y FastAPI. + + + +## Explorar y consultar datos + +Abre el **editor de Postgres** en el panel (`lizard open`) para ejecutar SQL y explorar tablas directamente. Para trabajo local puntual, ejecuta un comando con el entorno inyectado del servicio: + +```bash +lizard run --service api -- sh -c 'exec psql "$DATABASE_URL"' +``` + + + +## Ampliar almacenamiento + +Los volúmenes de datos solo pueden crecer: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Varias bases de datos + +Al añadir un segundo Postgres, recibe un nombre generado (p. ej., `postgres-autumn-bear`). Haz referencia a él explícitamente: + +```bash +lizard add postgres +lizard secrets set ANALYTICS_URL='${{postgres-autumn-bear.DATABASE_URL}}' --service api +``` + + + +## Ver también + +- [Managed Addons](/addons) — nomenclatura, referencias y los exploradores del panel. +- [Referencias entre servicios](/variables/references) — sintaxis y resolución de referencias. + +Consulta [almacenamiento y recuperación](/platform/storage-and-recovery) para planificar copias de seguridad y restauración. El `lizard run` local requiere `psql` y un endpoint de base de datos accesible; no se ejecuta dentro del servicio desplegado. diff --git a/_locales/es/addons/redis.mdx b/_locales/es/addons/redis.mdx new file mode 100644 index 0000000..090e9a4 --- /dev/null +++ b/_locales/es/addons/redis.mdx @@ -0,0 +1,79 @@ +--- +description: "Añade una instancia de Managed Redis para caché, colas, limitación de tasa y pub/sub, y conéctala a un servicio con una sola referencia." +--- + +# Managed Redis + +Una instancia de Managed Redis para caché, colas, limitación de tasa y pub/sub. + + + +## Aprovisionar + +```bash +lizard add redis +``` + +El primer addon de Redis se llama `redis`, así que `${{redis.REDIS_URL}}` funciona de inmediato. + + + +## Variables de entorno + +| Variable | Descripción | +|----------|-------------| +| `REDIS_URL` | Cadena de conexión completa (`redis://…`) | + + + +## Conectar un servicio + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard redeploy --service api +``` + +La referencia se resuelve en el momento del despliegue y rota junto con las credenciales del addon. + + + +## Usos comunes + +- **Caché** — almacena resultados calculados indexados por solicitud. +- **Cola / worker** — combina Redis con un [servicio en modo worker](/deploy/workers) que consume trabajos. +- **Limitación de tasa / sesiones** — estado compartido rápido entre [réplicas](/deploy/scaling). + +```bash +# A worker that drains a Redis queue +lizard add -r your-org/worker -n jobs +lizard service set jobs --set containerPort=0 +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service jobs +lizard redeploy --service jobs +``` + + + +## Explorar claves + +Abre el **navegador de Redis** en el panel (`lizard open`) para inspeccionar claves y valores. Para acceso local: + +```bash +lizard run --service api -- sh -c 'exec redis-cli -u "$REDIS_URL"' +``` + + + +## Ampliar almacenamiento + +```bash +lizard scale --service redis --storage 4096 +``` + + + +## Ver también + +- [Managed Addons](/addons) — nombres, referencias y los navegadores del panel. +- [Background Workers](/deploy/workers) — combinar Redis con un worker que consume colas. + +`lizard run` inicia el comando localmente con el entorno del servicio seleccionado. Instala `redis-cli` localmente y comprueba que se pueda acceder al endpoint. diff --git a/_locales/es/addons/storage.mdx b/_locales/es/addons/storage.mdx new file mode 100644 index 0000000..51d737a --- /dev/null +++ b/_locales/es/addons/storage.mdx @@ -0,0 +1,110 @@ +--- +description: "Almacenamiento de objetos compatible con S3 para cargas, recursos y copias de seguridad. Obtén un bucket de lectura pública y variables de conexión con un solo lizard add s3." +--- + + + +# Almacenamiento de objetos (S3) + +Almacenamiento de objetos compatible con S3 para cargas, recursos y copias de seguridad. Al aprovisionar un addon `s3` también se crea un **bucket de lectura pública llamado `default`**, para que puedas servir archivos sin configuración adicional. + + + +## Aprovisionar + +```bash +lizard add s3 +``` + +El primer addon de S3 se llama `s3`, así que `${{s3.S3_ENDPOINT}}` y similares funcionan de inmediato. + + + +## Variables de entorno + +| Variable | Descripción | +|----------|-------------| +| `S3_ENDPOINT` | URL del endpoint compatible con S3 | +| `S3_DEFAULT_BUCKET` | El nombre del bucket creado automáticamente (`default`) | +| `S3_ACCESS_KEY_ID` | Clave de acceso | +| `S3_SECRET_ACCESS_KEY` | Clave secreta | +| `S3_REGION` | Región | + + + +## Conectar un servicio + +```bash +lizard secrets set \ + S3_ENDPOINT='${{s3.S3_ENDPOINT}}' \ + S3_DEFAULT_BUCKET='${{s3.S3_DEFAULT_BUCKET}}' \ + S3_ACCESS_KEY_ID='${{s3.S3_ACCESS_KEY_ID}}' \ + S3_SECRET_ACCESS_KEY='${{s3.S3_SECRET_ACCESS_KEY}}' \ + S3_REGION='${{s3.S3_REGION}}' \ + --service api +lizard redeploy --service api +``` + + + +## Usar un AWS SDK + +El endpoint es compatible con S3. Configura direccionamiento de **estilo path**: + +```ts +import { S3Client } from "@aws-sdk/client-s3"; + +const s3 = new S3Client({ + endpoint: process.env.S3_ENDPOINT, + region: process.env.S3_REGION, + forcePathStyle: true, // required + credentials: { + accessKeyId: process.env.S3_ACCESS_KEY_ID!, + secretAccessKey: process.env.S3_SECRET_ACCESS_KEY!, + }, +}); +``` + + + +## Archivos públicos + +Los objetos en cualquier bucket **público** se sirven sin autenticación de dos maneras: + +1. **URL del gateway** (se muestra en el panel): + ``` + https://s3-.onlizard.com/// + ``` +2. **Proxy de la plataforma** (el host del panel, con encabezados de caché inmutables de larga duración): + ``` + /api/s3//public// + ``` + +Todo lo que se suba al bucket `default` es público inmediatamente en: + +``` +/api/s3//public/default/ +``` + + + +## Explorar objetos + +Abre el **navegador S3** en el panel (`lizard open`) para cargar, descargar y administrar objetos y buckets. + +> **Los cambios de ACL del bucket** (hacer un bucket público/privado) todavía no están en la CLI; gestiónalos desde el panel. + + + +## Ampliar almacenamiento + +```bash +lizard scale --service s3 --storage 16384 +``` + + + +## Ver también + +- [Addons gestionados](/addons) — nombres, referencias y los navegadores del panel. +- [Referencias entre servicios](/variables/references) — sintaxis de referencias y resolución. diff --git a/_locales/es/agents.mdx b/_locales/es/agents.mdx new file mode 100644 index 0000000..e0e8fa2 --- /dev/null +++ b/_locales/es/agents.mdx @@ -0,0 +1,92 @@ +--- +description: "Controla Lizard desde un agente de programación con IA: lee Lizard Skill, descubre los esquemas de comandos con --json y despliega mediante Lizard CLI." +--- + + + +# Agentes de programación + +Lizard está diseñado para ser manejado por agentes de programación con IA tan fácilmente como por humanos. La CLI incluye una **skill integrada** que le enseña a un agente toda la plataforma, y cada comando es **autodescriptivo** mediante `--json` para que los agentes nunca tengan que adivinar. + + + +## La skill integrada + +La guía de uso autoritativa vive dentro de la CLI y está versionada con ella, por lo que siempre coincide con la versión instalada. Un agente la lee con: + +```bash +lizard skills get core --json +``` + +Esto devuelve `{ name, frontmatter, content, … }` — `content` es la guía completa (pipeline de build, precedencia de env, addons, descubrimiento, códigos de salida). Subcomandos relacionados: + +```bash +lizard skills list # available embedded skills +lizard skills get core # the core guide +lizard skills path # where skills are stored +``` + +Como la guía viene incluida con el binario, `lizard upgrade` también actualiza las instrucciones del agente. + + + +## Comandos autodescriptivos + +Los agentes descubren la forma exacta de los flags en tiempo de ejecución en lugar de depender de una sintaxis memorizada: + +```bash +lizard --help --json # full command tree + exit codes +lizard --help --json # a specific command's schema +``` + +Consulta [JSON y automatización](/cli/json). + + + +## Inicialización dentro de un agente + +Un flujo típico de un agente: + +1. **Cargar la guía:** `lizard skills get core --json` → leer `content`. +2. **Verificar la autenticación de forma optimista:** ejecuta la tarea del usuario; con el código de salida `2`, ejecuta `lizard login`, entrega al usuario la URL impresa y luego reintenta. +3. **Resolver el contexto antes de modificar:** `lizard status` (enlace cwd) y `lizard ps --json` (servicios). +4. **Actuar** usando la guía — `add`, `up`, `secrets`, `domain`, etc., siempre con `--json`. + +Si el binario `lizard` no está presente, instálalo primero: + +```bash +npm install -g @lizard-build/cli +``` + + + +## Convenciones que los agentes deben seguir + +- **Pasa siempre `--json`** en llamadas no interactivas. +- **Confirma las acciones destructivas** (eliminar servicio, quitar addon, sobrescribir un secreto de todo el proyecto, reinicio de prod) con el usuario — los propios prompts de la CLI solo se activan en un TTY. +- **Limita los secretos al servicio que los consume** por defecto; reserva `--global` para valores demostrablemente públicos. Consulta [Variables y secretos](/variables#scoping). +- **No escribas Dockerfiles sin que se soliciten** — lizardpack detecta automáticamente la mayoría de los stacks. Prueba primero un despliegue. Consulta [Pipeline de build](/concepts/build-pipeline). +- **No uses `lizard up` para cambiar un servicio respaldado por git a upload** — usa `service set` + `redeploy`. + + + +## Integraciones con editores + +Lizard Skill se distribuye como un bootstrap público para que los agentes en editores y asistentes puedan instalarla y cargarla bajo demanda, y luego manejar la misma CLI descrita a lo largo de esta documentación. La CLI es la única fuente de verdad — no hay una API separada de agentes que aprender. + +Eso también cubre los IDE con IA: escriben y prueban una app, pero no la alojan. Consulta [desplegar una app creada en Google Antigravity](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command), donde todo el despliegue se ejecuta desde dos prompts. + + + +## Ver también + +- [`lizard skills`](/cli/skills) — la referencia completa de comandos. +- [JSON y automatización](/cli/json) — salida `--json` y descubrimiento de esquemas. +- [Variables y secretos](/variables#scoping) — convenciones de alcance de secretos que los agentes deben seguir. +- [Despliega tu app desde Claude Code](https://lizard.build/blog/deploy-from-claude-code#deploy-from-claude-code-in-3-steps) — el mismo bootstrap escrito como guía paso a paso, con los prompts que lo impulsan. + + + +## Alojar tu propio servidor MCP + +Un agente que usa Lizard CLI y una aplicación que expone MCP son flujos de trabajo separados. Los comandos de CLI anteriores no proporcionan un transporte MCP. Para desplegar tu propio servidor con Streamable HTTP, sigue la [guía de MCP remoto](/guides/deploy-mcp-server). diff --git a/_locales/es/cli/_meta.ts b/_locales/es/cli/_meta.ts new file mode 100644 index 0000000..d787f06 --- /dev/null +++ b/_locales/es/cli/_meta.ts @@ -0,0 +1,46 @@ +export default { + index: "Resumen", + json: "JSON y automatización", + '-- auth': { type: "separator", title: "Autenticación y cuenta" }, + login: "login", + logout: "logout", + whoami: "whoami", + workspace: "workspace", + '-- projects': { type: "separator", title: "Proyectos y vinculación" }, + init: "init", + link: "link", + unlink: "unlink", + status: "status", + project: "project", + config: "config", + '-- create': { type: "separator", title: "Creación de servicios y addons" }, + add: "add", + '-- deploy': { type: "separator", title: "Despliegue" }, + up: "up", + redeploy: "redeploy", + restart: "restart", + '-- svc': { type: "separator", title: "Configuración del servicio" }, + service: "service", + port: "port", + scale: "scale", + '-- secrets': { type: "separator", title: "Secrets" }, + secrets: "secrets", + '-- domains': { type: "separator", title: "Dominios" }, + domain: "domain", + '-- observability': { type: "separator", title: "Logs, métricas y eventos" }, + logs: "logs", + metrics: "metrics", + events: "events", + ps: "ps", + '-- running': { type: "separator", title: "Ejecución de comandos" }, + run: "run", + ssh: "ssh", + '-- github': { type: "separator", title: "GitHub" }, + git: "git", + '-- misc': { type: "separator", title: "Varios" }, + regions: "regions", + open: "open", + docs: "docs", + upgrade: "upgrade", + skills: "skills", +}; diff --git a/_locales/es/cli/add.mdx b/_locales/es/cli/add.mdx new file mode 100644 index 0000000..26431f9 --- /dev/null +++ b/_locales/es/cli/add.mdx @@ -0,0 +1,78 @@ +--- +description: "lizard add crea un servicio desde un repositorio de GitHub, un servicio vacío o un addon gestionado. Referencia completa de flags con ejemplos prácticos." +--- + +# lizard add + +Añade una base de datos, servicio o repositorio al proyecto. + + + +## Uso + +```bash +lizard add [types...] [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-r, --repo ` | Crear un servicio desde un repositorio de GitHub | +| `-s, --service ` | Crear un servicio vacío | +| `-a, --addon ` | Añadir addons gestionados (`postgres` / `redis` / `s3`) | +| `-n, --name ` | Nombre usado en las referencias de `${{name.KEY}}` | +| `-v, --variables ` | Inicializar una variable de entorno (repetible) | +| `--region ` | Región en la que aprovisionar | +| `--no-deploy` | Adjuntar repositorio pero omitir la primera compilación | +| `--list` | Mostrar los tipos de base de datos disponibles | + + + +## Ejemplos + + + +### Crear un servicio desde un repositorio de GitHub + +```bash +lizard add -r your-org/your-app +``` + +Esto crea un servicio con código fuente en `github`, clona el repositorio, detecta automáticamente el stack, lo compila y devuelve una URL activa. + + + +### Aprovisionar addons + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +### Crear un servicio vacío + +```bash +lizard add -s worker +``` + + + +### Asignar un nombre a un servicio e inicializar variables + +```bash +lizard add -r your-org/monorepo -n api +``` + + + +## Véase también + +- [Desplegar desde GitHub](/deploy/github) — conectar repositorios, acceso privado y redespliegue automático al hacer push +- [Addons gestionados](/addons) — aprovisionamiento, nombres y uso de postgres/redis/s3 +- [lizard up](/cli/up) — subir y desplegar el directorio actual en lugar de vincular un repositorio diff --git a/_locales/es/cli/config.mdx b/_locales/es/cli/config.mdx new file mode 100644 index 0000000..818b6db --- /dev/null +++ b/_locales/es/cli/config.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard config apply envía un archivo lizard-config.json a tu proyecto, con una opción --dry-run para previsualizar primero los cambios." +--- + +# lizard config + +Aplica un archivo `lizard-config.json` al proyecto. + + + +## Uso + +```bash +lizard config apply [flags] +``` + + + +## Subcomandos + +### `lizard config apply` + +Aplica un archivo `lizard-config.json` al proyecto. + +| Bandera | Descripción | +|------|-------------| +| `-f, --file ` | Archivo de configuración (por defecto `lizard-config.json`) | +| `--dry-run` | Muestra qué cambiaría sin aplicar | + + + +## Ejemplos + + + +### Aplicar el archivo de configuración predeterminado + +```bash +lizard config apply +``` + + + +### Aplicar un archivo de configuración desde una ruta personalizada + +```bash +lizard config apply -f ./configs/prod.json +``` + + + +### Previsualizar cambios sin aplicarlos + +```bash +lizard config apply --dry-run +``` + + + +## Ver también + +- [lizard service](/cli/service) — gestionar servicios individuales +- [Architecture](/concepts/architecture) — cómo se relacionan los workspaces, proyectos y servicios diff --git a/_locales/es/cli/docs.mdx b/_locales/es/cli/docs.mdx new file mode 100644 index 0000000..12c38df --- /dev/null +++ b/_locales/es/cli/docs.mdx @@ -0,0 +1,33 @@ +--- +description: "lizard docs abre la documentación de Lizard en tu navegador predeterminado directamente desde la terminal. Uso y ejemplos." +--- + +# lizard docs + +Abre la documentación en el navegador. + + + +## Uso + +```bash +lizard docs +``` + + + +## Ejemplos + + + +### Abrir el sitio de documentación + +```bash +lizard docs +``` + + + +## Ver también + +- [Referencia de CLI](/cli) — instalación, indicadores globales y códigos de salida diff --git a/_locales/es/cli/domain.mdx b/_locales/es/cli/domain.mdx new file mode 100644 index 0000000..f1dfec8 --- /dev/null +++ b/_locales/es/cli/domain.mdx @@ -0,0 +1,104 @@ +--- +description: "lizard domain muestra el dominio de un servicio, genera un subdominio de onlizard.com, o adjunta y verifica un hostname personalizado con TLS automático." +--- + +# lizard domain + +Muestra el dominio actual o adjunta uno personalizado. + + + +## Uso + +```bash +lizard domain [hostname] [flags] +``` + +El hostname es un argumento posicional: no existe el subcomando `add`. Ejecutar `lizard domain` sin argumentos muestra el dominio actual del servicio. + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-s, --service ` | Servicio | +| `--port ` | Puerto que se expondrá | + + + +## Subcomandos + +### `lizard domain generate` + +Genera un subdominio nuevo de `*.onlizard.com`. + +### `lizard domain verify ` + +Comprueba el registro TXT y activa el dominio. TLS se aprovisiona automáticamente. + +### `lizard domain delete ` + +Elimina un dominio (alias `rm`). + +| Bandera | Descripción | +|------|-------------| +| `-y, --yes` | Omitir confirmación | + + + +## Ejemplos + + + +### Mostrar el dominio actual + +```bash +lizard domain +``` + + + +### Generar un subdominio + +```bash +lizard domain generate +``` + + + +### Adjuntar un dominio personalizado + +```bash +lizard domain app.example.com --service web +``` + +Lizard devuelve los registros DNS que debes crear (un registro `CNAME` para el hostname y un registro `TXT` para la verificación). Agrégalos en tu proveedor de DNS y luego verifica: + +```bash +lizard domain verify app.example.com +``` + + + +### Adjuntar un dominio a un puerto específico + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +### Eliminar un dominio + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes +``` + + + +## Véase también + +- [Networking](/networking) — dominios generados, TLS y servicios worker +- [Desplegar a regiones](/deploy/regions) — selección de región para servicios diff --git a/_locales/es/cli/events.mdx b/_locales/es/cli/events.mdx new file mode 100644 index 0000000..1da918f --- /dev/null +++ b/_locales/es/cli/events.mdx @@ -0,0 +1,60 @@ +--- +description: "lizard events muestra el historial de despliegues de un servicio y el estado actual de las réplicas, con opciones para limitar las entradas o apuntar a un servicio." +--- + +# lizard events + +Muestra el historial de despliegues y el estado de las réplicas. + + + +## Uso + +```bash +lizard events [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-n, --limit ` | Número de entradas que se mostrarán (por defecto 10) | +| `-s, --service ` | Muestra los eventos de un servicio específico | + + + +## Ejemplos + + + +### Mostrar el historial de despliegues y el estado de las réplicas + +```bash +lizard events +``` + + + +### Mostrar eventos de un servicio específico + +```bash +lizard events --service api +``` + + + +### Mostrar más entradas + +```bash +lizard events --limit 25 +``` + + + +## Véase también + +- [Events & History](/observability/events) — qué cubre cada entrada y cómo se corresponde con la vista Despliegues del panel +- [lizard ps](/cli/ps) — una vista rápida del estado y la URL de todos los servicios +- [Despliegues](/concepts/deployments) — el ciclo de vida del despliegue diff --git a/_locales/es/cli/git.mdx b/_locales/es/cli/git.mdx new file mode 100644 index 0000000..0e79fde --- /dev/null +++ b/_locales/es/cli/git.mdx @@ -0,0 +1,80 @@ +--- +description: "lizard git conecta la GitHub App, informa el estado del repositorio y cambia un servicio a otra rama con un redespliegue." +--- + +# lizard git + +Administra la conexión de GitHub para el proyecto vinculado y sus servicios. + + + +## Uso + +```bash +lizard git connect +lizard git status +lizard git checkout [flags] +``` + + + +## Subcomandos + +### `lizard git connect` + +Conecta la GitHub App para acceder a repositorios privados. + +### `lizard git status` + +Muestra la conexión de GitHub y el estado del repositorio. + +### `lizard git checkout ` + +Cambia un servicio a una rama diferente y vuelve a desplegarlo. + +| Bandera | Descripción | +|------|-------------| +| `--detach` | Omitir la transmisión de logs | + + + +## Ejemplos + + + +### Conectar la GitHub App + +```bash +lizard git connect +``` + + + +### Comprobar la conexión y el estado del repositorio + +```bash +lizard git status +``` + + + +### Cambiar un servicio a una rama diferente + +```bash +lizard git checkout api staging +``` + + + +### Cambiar de rama sin transmitir logs + +```bash +lizard git checkout api staging --detach +``` + + + +## Ver también + +- [Desplegar desde GitHub](/deploy/github) — conectar un repo, redespliegue automático al hacer push y configuración de monorepo +- [lizard add](/cli/add) — crear un servicio desde un repo de GitHub diff --git a/_locales/es/cli/index.mdx b/_locales/es/cli/index.mdx new file mode 100644 index 0000000..87cd490 --- /dev/null +++ b/_locales/es/cli/index.mdx @@ -0,0 +1,88 @@ +--- +description: "Instala y actualiza lizard CLI, autentícate y consulta las banderas globales, los códigos de salida y el descubrimiento del esquema en tiempo de ejecución para cada comando." +--- + + + +# Referencia de CLI + +La CLI de `lizard` es la interfaz principal de la plataforma. Esta página cubre la instalación, las banderas globales, los códigos de salida y el descubrimiento en tiempo de ejecución. Cada comando tiene su propia página de referencia en la barra lateral: consulta [`lizard up`](/cli/up), [`lizard service`](/cli/service), [`lizard secrets`](/cli/secrets) y el resto. + +> Referencia generada con la CLI **v0.3.62**. Ejecuta `lizard --help --json` para obtener el esquema exacto de cualquier comando, correspondiente a tu versión. + + + +## Instalar y actualizar + +```bash +npm install -g @lizard-build/cli +lizard --version +lizard upgrade # update to the latest version +lizard upgrade --check # check without installing +``` + +Usa siempre el binario `lizard` instalado globalmente, **no** `npx`. Consulta [Quickstart](/getting-started#1-install-the-cli) para corregir errores de permisos. + + + +## Autenticación + +```bash +lizard login # browser OAuth +lizard login --token lzd_xxx # token auth +lizard logout +lizard whoami # current user, workspace, linked project +``` + +En CI, configura `LIZARD_TOKEN` en el entorno en lugar de ejecutar `login`. + + + +## Banderas globales + +| Bandera | Descripción | +|------|-------------| +| `-V, --version` | Muestra la versión de la CLI | +| `--json` | Salida legible por máquinas. Combínala con `--help` para volcar el esquema de un comando | + +La mayoría de los comandos también aceptan `-p, --project`, `-s, --service` y `-w, --workspace` para apuntar a un recurso específico en lugar del enlazado. + + + +## Códigos de salida + +| Código | Significado | Qué hacer | +|------|---------|------------| +| `0` | éxito | continuar | +| `1` | error genérico | lee el mensaje | +| `2` | auth (401/403) | ejecuta `lizard login` | +| `3` | no encontrado (404) | comprueba el nombre con `lizard ps` / `lizard project list` | +| `4` | tiempo de espera agotado (408/504) | reintenta | +| `5` | cancelado por el usuario | detente | + + + +## Descubrimiento en tiempo de ejecución + +La CLI se autodocumenta. Para ver el árbol completo de comandos, las banderas globales y los códigos de salida: + +```bash +lizard --help --json +``` + +Para ver los argumentos y opciones exactos de cualquier comando o subcomando: + +```bash +lizard --help --json +lizard --help --json # e.g. lizard service set --help --json +``` + +Esto siempre refleja tu versión instalada; es preferible a adivinar la forma de las banderas. También es como un agente aprende la CLI sin haber sido entrenado con ella: consulta [despliegue desde Claude Code](https://lizard.build/blog/deploy-from-claude-code). + + + +## Configuración y estado + +- La CLI almacena la autenticación y el enlace del proyecto del directorio actual en `~/.lizard/config.json`. +- `lizard status` muestra el enlace de workspace/proyecto/servicio del cwd (no requiere autenticación). +- `lizard config apply` aplica un archivo `lizard-config.json` a un proyecto (usa `--dry-run` para previsualizar). diff --git a/_locales/es/cli/init.mdx b/_locales/es/cli/init.mdx new file mode 100644 index 0000000..6e51cab --- /dev/null +++ b/_locales/es/cli/init.mdx @@ -0,0 +1,66 @@ +--- +description: "lizard init crea o selecciona un proyecto y lo vincula al directorio actual, incluida la forma explícita que necesitas en CI." +--- + +# lizard init + +Crea o selecciona un proyecto y lo vincula al directorio actual. + + + +## Uso + +```bash +lizard init [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-n, --name ` | Nombre del proyecto (créalo si no existe) | +| `-w, --workspace ` | ID, slug o nombre del workspace | +| `--force` | Volver a vincular aunque ya esté vinculado | + + + +## Ejemplos + + + +### Vincular el directorio actual de forma interactiva + +```bash +lizard init +``` + + + +### Vincular explícitamente en CI + +`lizard up` ejecutará `init` por ti en un TTY, pero en un entorno no TTY (CI) devuelve un error en lugar de crear un proyecto silenciosamente. Vincúlalo explícitamente primero: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +### Volver a vincular un directorio que ya está vinculado + +```bash +lizard init --name my-project --force +``` + + + +## Véase también + +- [lizard link](/cli/link) — asocia el directorio actual con un proyecto existente en lugar de crear uno +- [lizard status](/cli/status) — muestra el workspace, proyecto y servicio vinculados para el directorio actual +- [lizard up](/cli/up) — sube e implementa el directorio actual +- [Core Conceptos](/concepts/architecture) — proyectos, servicios y el pipeline de compilación diff --git a/_locales/es/cli/json.mdx b/_locales/es/cli/json.mdx new file mode 100644 index 0000000..f10cc49 --- /dev/null +++ b/_locales/es/cli/json.mdx @@ -0,0 +1,92 @@ +--- +description: "Programa el lizard CLI: --json en cada comando, eventos delimitados por líneas para compilaciones en streaming, descubrimiento de esquemas y autenticación por token en CI." +--- + + + +# JSON y automatización + +La CLI está hecha para automatizarse con scripts. Pasa `--json` para obtener salida legible por máquinas, contrólala desde CI con un token y descubre el esquema de cualquier comando en tiempo de ejecución. + +El otro lector de esta salida es un agente de programación con IA: [despliegue desde Claude Code](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) muestra qué hace con el JSON de una compilación fallida. + + + +## `--json` en todas partes + +Añade `--json` a cualquier comando para obtener salida estructurada. La CLI también cambia a JSON automáticamente cuando stdout no es un TTY. + +```bash +lizard ps --json +lizard secrets list --json +lizard metrics --json +``` + + + +### Comandos en streaming + +Para los comandos en streaming (`lizard up` sin `--detach`), `--json` emite **un objeto JSON por línea**: + +```json +{ "event": "log", "line": "Step 1/8 : FROM node:20" } +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "running", "url": "https://app.onlizard.com" } +``` + +El stream termina con `done`, o `error` / `failed`. `lizard up` además emite un evento final `deployed` / `failed` / `deploying` con `status` y `url` (que puede ser `null`). + + + +### `logs --json` es una instantánea, no un stream + +`lizard logs --json` devuelve las **últimas 200 líneas** (se puede cambiar con `--tail N`, máximo 1000) y sale. No esperes más salida de él. + +Para un incidente específico, usa `--restart latest` o `--restart `. + + + +## Descubrimiento de esquemas + +Muestra los argumentos, opciones y códigos de salida exactos de cualquier comando: + +```bash +lizard --help --json # whole tree + global flags + exit codes +lizard service set --help --json # one command +``` + +La forma de la respuesta es `{ cli, version, command: { arguments, options, subcommands }, globalOptions, exitCodes }`. Como se genera a partir del binario instalado, siempre coincide con tu versión; úsala de preferencia en lugar de fijar flags manualmente. + + + +## Uso en CI / sin interfaz + +Autentícate con un token y vincula el proyecto explícitamente (`up` sin interfaz no creará un proyecto automáticamente): + +```bash +# Set LIZARD_TOKEN through your CI secret store. +lizard init --name my-project +lizard up --ci --service api --detach +``` + +Comprueba los códigos de salida para decidir el flujo de tu pipeline: + +| Código | Significado | +|------|---------| +| `0` | éxito | +| `1` | error genérico | +| `2` | auth — token ausente/caducado | +| `3` | no encontrado | +| `4` | tiempo de espera agotado | +| `5` | cancelado | + +```bash +if lizard redeploy --service api --json; then + echo "Deploy succeeded" +else + status=$? + echo "Deploy failed with code $status" >&2 + lizard logs --build --json || true + exit "$status" +fi +``` diff --git a/_locales/es/cli/link.mdx b/_locales/es/cli/link.mdx new file mode 100644 index 0000000..4fa7303 --- /dev/null +++ b/_locales/es/cli/link.mdx @@ -0,0 +1,62 @@ +--- +description: "lizard link asocia el directorio actual con un proyecto existente y, opcionalmente, con un servicio o espacio de trabajo específico." +--- + +# lizard link + +Asocia el directorio actual con un proyecto existente (y opcionalmente con un servicio). + + + +## Uso + +```bash +lizard link [service] [flags] +``` + + + +## Indicadores + +| Bandera | Descripción | +|------|-------------| +| `-p, --project ` | Nombre del proyecto, slug o ID | +| `-s, --service ` | Servicio para vincular | +| `-w, --workspace ` | Espacio de trabajo | + + + +## Ejemplos + + + +### Vincular a un proyecto existente + +```bash +lizard link --project my-project +``` + + + +### Vincular a un proyecto y a un servicio específico + +```bash +lizard link my-service --project my-project +``` + + + +### Vincular dentro de un espacio de trabajo específico + +```bash +lizard link --project my-project --workspace my-workspace +``` + + + +## Ver también + +- [lizard init](/cli/init) — crea o selecciona un proyecto y lo vincula en un solo paso +- [lizard unlink](/cli/unlink) — elimina el vínculo del directorio actual +- [lizard status](/cli/status) — muestra el espacio de trabajo, proyecto y servicio vinculados +- [Architecture: Proyecto](/concepts/architecture) — cómo funciona el vínculo entre directorio y proyecto diff --git a/_locales/es/cli/login.mdx b/_locales/es/cli/login.mdx new file mode 100644 index 0000000..f751317 --- /dev/null +++ b/_locales/es/cli/login.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard login autentica a través de tu navegador o de un token de API, además de cómo autenticar de forma no interactiva en CI con LIZARD_TOKEN." +--- + +# lizard login + +Inicia sesión en Lizard. + + + +## Uso + +```bash +lizard login [flags] +``` + +De forma predeterminada, esto abre tu navegador para autenticarte mediante OAuth y luego vuelve a tu terminal una vez que confirmas. + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `--token ` | Autenticar con un token de API | + + + +## Ejemplos + + + +### Iniciar sesión mediante el navegador + +```bash +lizard login +``` + + + +### Iniciar sesión con un token + +```bash +lizard login --token lzd_xxx +``` + + + +### Iniciar sesión de forma no interactiva en CI + +En CI u otros entornos no interactivos, configura `LIZARD_TOKEN` en el entorno en lugar de ejecutar `login`: + +```bash +export LIZARD_TOKEN=lzd_xxx +``` + + + +## Ver también + +- [lizard logout](/cli/logout) — cerrar sesión +- [lizard whoami](/cli/whoami) — mostrar el usuario actual, el workspace activo y el proyecto vinculado +- [CLI reference](/cli) — flags globales, códigos de salida y resumen de autenticación diff --git a/_locales/es/cli/logout.mdx b/_locales/es/cli/logout.mdx new file mode 100644 index 0000000..094164c --- /dev/null +++ b/_locales/es/cli/logout.mdx @@ -0,0 +1,22 @@ +--- +description: "lizard logout cierra tu sesión de Lizard CLI y borra las credenciales almacenadas en esta máquina. Vuelve a iniciar sesión con lizard login." +--- + +# lizard logout + +Cerrar sesión. + + + +## Uso + +```bash +lizard logout +``` + + + +## Ver también + +- [lizard login](/cli/login) — autenticar con Lizard +- [lizard whoami](/cli/whoami) — mostrar el usuario actual, el workspace activo y el proyecto vinculado diff --git a/_locales/es/cli/logs.mdx b/_locales/es/cli/logs.mdx new file mode 100644 index 0000000..6f26aa7 --- /dev/null +++ b/_locales/es/cli/logs.mdx @@ -0,0 +1,93 @@ +--- +description: "lizard logs transmite los logs de ejecución de un servicio, o recupera logs de compilación, logs de reinicio e historial filtrado con --build, --tail y --level." +--- + +# lizard logs + +Transmite los logs de ejecución de un servicio, las últimas 200 líneas seguidas de una cola en vivo. + + + +## Uso + +```bash +lizard logs [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `--build` | Mostrar los logs de compilación en su lugar | +| `--tail ` | Últimas N líneas (máx. 1000) | +| `-l, --level ` | Filtrar por nivel | +| `--restarts [n]` | Listar reinicios recientes | +| `--restart ` | Logs alrededor de un reinicio específico (`latest` para el más reciente) | +| `-s, --service ` | Servicio | + +Con `--json`, `lizard logs` no es un flujo: devuelve las últimas 200 líneas (anúlalo con `--tail N`, máximo 1000) y sale. Úsalo para capturas y scripts; transmite en vivo solo sin `--json`. + + + +## Ejemplos + + + +### Ver logs de ejecución en tiempo real + +```bash +lizard logs +``` + + + +### Ver logs de un servicio específico en tiempo real + +```bash +lizard logs --service api +``` + + + +### Obtener más historial + +```bash +lizard logs --tail 1000 +``` + + + +### Filtrar por nivel de log + +```bash +lizard logs --level error +``` + + + +### Revisar la compilación más reciente + +```bash +lizard logs --build +``` + + + +### Inspeccionar un fallo o reinicio + +```bash +lizard logs --restarts +lizard logs --restart latest +lizard logs --restart +``` + + + +## Véase también + +- [Logs](/observability/logs) — comportamiento de los logs de ejecución, compilación y reinicio, además de la paginación por el historial con `lizard service logs` +- [Incomplete Dockerfile](/deploy/troubleshooting/incomplete-dockerfile) — diagnosticar una compilación fallida desde `lizard logs --build` +- [lizard events](/cli/events) — historial de despliegues y estado de las réplicas +- [Desplegar desde Claude Code](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) — el ciclo de leer logs, corregir y volver a desplegar que ejecuta un agente en una compilación fallida diff --git a/_locales/es/cli/metrics.mdx b/_locales/es/cli/metrics.mdx new file mode 100644 index 0000000..da69d7b --- /dev/null +++ b/_locales/es/cli/metrics.mdx @@ -0,0 +1,68 @@ +--- +description: "lizard metrics informa CPU, memoria, red y disco para un servicio, con una vista en vivo con --watch y cifras de costo opcionales." +--- + +# lizard metrics + +Muestra CPU / memoria / red / disco y costo. + + + +## Uso + +```bash +lizard metrics [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-r, --range ` | Ventana de tiempo | +| `-w, --watch` | Actualización en vivo | +| `--cost` | Incluir costo | + + + +## Ejemplos + + + +### Ver métricas del servicio actual + +```bash +lizard metrics +``` + + + +### Ver métricas de un servicio específico + +```bash +lizard metrics --service api +``` + + + +### Ver métricas en vivo + +```bash +lizard metrics --watch +``` + + + +### Incluir costo + +```bash +lizard metrics --cost +``` + + + +## Ver también + +- [Métricas y costo](/observability/metrics) — vistas del panel y cómo actuar según el uso +- [Escalado](/deploy/scaling) — cambiar el tamaño o añadir réplicas en respuesta a las métricas diff --git a/_locales/es/cli/open.mdx b/_locales/es/cli/open.mdx new file mode 100644 index 0000000..dbc9b0c --- /dev/null +++ b/_locales/es/cli/open.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard open abre el panel del proyecto actual en tu navegador, el complemento visual del CLI." +--- + +# lizard open + +Abre el proyecto en el navegador. + + + +## Uso + +```bash +lizard open +``` + + + +## Ejemplos + + + +### Abrir el panel del proyecto actual + +```bash +lizard open +``` + + + +## Ver también + +- [Panel](/dashboard) — el complemento visual del CLI que abre este comando +- [Desplegar una app Antigravity a producción](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command) — ver cómo se completa un despliegue ejecutado por un agente, sin escribir un comando tú mismo diff --git a/_locales/es/cli/port.mdx b/_locales/es/cli/port.mdx new file mode 100644 index 0000000..aa6aa52 --- /dev/null +++ b/_locales/es/cli/port.mdx @@ -0,0 +1,59 @@ +--- +description: "lizard port muestra o cambia el puerto del contenedor de un servicio. Establecerlo en 0 pone el servicio en modo worker sin enrutamiento de entrada." +--- + +# lizard port + +Muestra o cambia el puerto del contenedor de un servicio. Sin argumentos, imprime el puerto actual (`worker mode` cuando es `0`). + + + +## Uso + +```bash +lizard port [value] [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-s, --service ` | Servicio de destino | + + + +## Ejemplos + + + +### Mostrar el puerto actual + +```bash +lizard port +``` + + + +### Establecer el puerto para un servicio específico + +```bash +lizard port 0 -s worker +``` + + + +### Comprobar el puerto en un servicio worker + +```bash +lizard port --service worker +``` + + + +## Ver también + +- [Workers en segundo plano](/deploy/workers) — establece el puerto en `0` para ejecutar un servicio sin enrutamiento de entrada +- [lizard service](/cli/service) — administra el resto de la configuración de un servicio +- [Lo que una app de Python necesita de un host](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) — por qué un proceso `gunicorn` o `uvicorn` tiene que enlazarse a `$PORT` en `0.0.0.0` diff --git a/_locales/es/cli/project.mdx b/_locales/es/cli/project.mdx new file mode 100644 index 0000000..d316c9a --- /dev/null +++ b/_locales/es/cli/project.mdx @@ -0,0 +1,56 @@ +--- +description: "lizard project muestra los proyectos en tu espacio de trabajo o crea uno nuevo, con ejemplos para ambos subcomandos." +--- + +# lizard project + +Muestra o crea proyectos en un espacio de trabajo. + + + +## Uso + +```bash +lizard project list +lizard project create +``` + + + +## Subcomandos + +### `lizard project list` + +Muestra todos los proyectos en el espacio de trabajo. + +### `lizard project create` + +Crea un nuevo proyecto. + + + +## Ejemplos + + + +### Mostrar proyectos en el espacio de trabajo + +```bash +lizard project list +``` + + + +### Crear un nuevo proyecto + +```bash +lizard project create +``` + + + +## Véase también + +- [lizard init](/cli/init) — crea o selecciona un proyecto y lo vincula al directorio actual +- [lizard link](/cli/link) — asocia el directorio actual con un proyecto existente +- [Arquitectura](/concepts/architecture) — cómo se relacionan los proyectos con los espacios de trabajo y los servicios diff --git a/_locales/es/cli/ps.mdx b/_locales/es/cli/ps.mdx new file mode 100644 index 0000000..a0a94b4 --- /dev/null +++ b/_locales/es/cli/ps.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard ps enumera cada servicio en el proyecto vinculado con su estado y URL activa, una vista rápida de lo que está en ejecución." +--- + +# lizard ps + +Enumera todos los servicios del proyecto con su estado y URL. + + + +## Uso + +```bash +lizard ps +``` + + + +## Ejemplos + + + +### Enumerar servicios en el proyecto vinculado + +```bash +lizard ps +``` + + + +## Véase también + +- [lizard status](/cli/status) — mostrar el workspace, proyecto y servicio vinculados para el directorio actual +- [lizard events](/cli/events) — mostrar el historial de despliegues y el estado de las réplicas diff --git a/_locales/es/cli/redeploy.mdx b/_locales/es/cli/redeploy.mdx new file mode 100644 index 0000000..a213331 --- /dev/null +++ b/_locales/es/cli/redeploy.mdx @@ -0,0 +1,69 @@ +--- +description: "lizard redeploy activa una compilación nueva desde el commit más reciente o la última carga usando las variables actuales, transmitiendo los registros salvo que pases --detach." +--- + +# lizard redeploy + +Activa una compilación nueva (commit más reciente / última carga) con las variables actuales. + + + +## Uso + +```bash +lizard redeploy [nameOrId] [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|--------------| +| `-s, --service ` | Servicio | +| `--detach` | Volver después de que se acepte la compilación | +| `--wait` | Esperar a la compilación y a que el despliegue esté listo; funciona con `--json` | +| `--timeout ` | Tiempo de espera para la preparación después de la compilación; valor predeterminado `120` | +| `--json` | Devolver JSON para scripts | + + + +## Ejemplos + + + +### Volver a compilar y redesplegar un servicio + +```bash +lizard redeploy --service api +``` + + + +### Redesplegar sin transmitir registros + +```bash +lizard redeploy --service api --detach +``` + + + +### Esperar en un script + +Requiere CLI 0.3.94 o posterior. Usa 0.3.95 o posterior para workers sin HTTP. + +```bash +lizard --json redeploy --service api --wait --timeout 120 +``` + +Sin `--wait`, el modo JSON devuelve el resultado después de que se acepta la solicitud de compilación. Con `--wait`, el CLI sigue esa compilación y luego espera a que el despliegue esté listo. El resultado JSON incluye `buildId`, `ok` y `status`. Un fallo de compilación, una comprobación de preparación fallida o un tiempo de espera agotado devuelven un código de salida distinto de cero. + +El tiempo de espera se aplica a la preparación después de que termine la compilación; no limita la duración de la compilación ni cancela el despliegue. Los workers con `containerPort=0` usan el estado de preparación del backend sin una comprobación HTTP. Después de un comando correcto, comprueba un endpoint de la aplicación o los datos almacenados si tu flujo de trabajo necesita verificar el comportamiento de la aplicación. + + + +## Ver también + +- [lizard restart](/cli/restart) — reinicio gradual de la compilación actual, sin recompilar +- [lizard up](/cli/up) — carga el directorio actual y lo despliega +- [Despliegues](/concepts/deployments) — cómo funcionan los despliegues, reinicios y recompilaciones diff --git a/_locales/es/cli/regions.mdx b/_locales/es/cli/regions.mdx new file mode 100644 index 0000000..6f803a7 --- /dev/null +++ b/_locales/es/cli/regions.mdx @@ -0,0 +1,64 @@ +--- +description: "lizard regions lista las regiones disponibles para tu cuenta y muestra cómo pasar --region al crear un servicio o addon." +--- + +# lizard regions + +Lista las regiones disponibles. + + + +## Uso + +```bash +lizard regions [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `--json` | Salida en JSON | + + + +## Ejemplos + + + +### Listar regiones disponibles + +```bash +lizard regions +``` + + + +### Listar regiones como JSON + +```bash +lizard regions --json +``` + + + +### Elegir una región al crear un servicio o addon + +Pasa `--region ` a `lizard add` o `lizard up`: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +Si no especificas una región, la plataforma usa la predeterminada del proyecto. + + + +## Véase también + +- [Regiones](/deploy/regions) — selección de región, co-ubicación y dominios generados +- [`lizard add`](/cli/add) — añade un servicio, repositorio o addon con `--region` diff --git a/_locales/es/cli/restart.mdx b/_locales/es/cli/restart.mdx new file mode 100644 index 0000000..40e89be --- /dev/null +++ b/_locales/es/cli/restart.mdx @@ -0,0 +1,75 @@ +--- +description: "lizard restart realiza un reinicio gradual de la compilación actual de un servicio sin reconstrucción, útil para recuperarse de un fallo." +--- + +# lizard restart + +Reinicio gradual de la compilación actual — sin reconstrucción. + + + +## Uso + +```bash +lizard restart [nameOrId] [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|--------------| +| `-s, --service ` | Servicio | +| `--detach` | Volver después de que se acepte el reinicio | +| `--wait` | Esperar a que el nuevo intento de reinicio esté listo; funciona con `--json` | +| `--timeout ` | Tiempo máximo de espera de preparación con `--wait`; valor predeterminado: `120` | +| `--json` | Devolver JSON para scripts | + + + +## Ejemplos + + + +### Reiniciar un servicio + +```bash +lizard restart --service api +``` + + + +### Reiniciar sin transmitir logs + +```bash +lizard restart --service api --detach +``` + + + +### Esperar antes de ejecutar la siguiente comprobación + +Requiere CLI 0.3.94 o posterior. Usa 0.3.95 o posterior para workers sin HTTP. + +```bash +lizard --json restart --service api --wait --timeout 120 +``` + +Sin `--wait`, el modo JSON devuelve el resultado después de que se acepte el reinicio. Con `--wait`, el resultado incluye `ok`, `status`, `attemptId` y `waitedMs`. La CLI espera un nuevo intento de reinicio, por lo que un estado sin cambios desde antes de la solicitud no cuenta como éxito. Una espera fallida o un tiempo de espera agotado devuelve un código de salida distinto de cero. + +Para los servicios HTTP, la CLI también comprueba dos veces el dominio del servicio. Los workers con `containerPort=0` usan el estado de preparación del backend y no necesitan un listener HTTP, incluso cuando tienen un dominio generado. + +```bash +lizard --json restart --service worker --wait --timeout 60 +``` + +El tiempo de espera se aplica a la espera de preparación después de la solicitud de reinicio. No cancela el reinicio, y las llamadas de red pueden hacer que el comando tarde más en total. Comprueba los datos de la aplicación o un endpoint de estado después del comando cuando tu flujo de trabajo necesite más que la preparación del proceso. + + + +## Véase también + +- [lizard redeploy](/cli/redeploy) — activar una nueva compilación en lugar de reciclar la actual +- [lizard logs](/cli/logs) — inspeccionar los logs en torno a un reinicio con `--restart latest` o `--restart ` +- [Despliegues](/concepts/deployments) — reinicios frente a redespliegues y recuperación tras un fallo diff --git a/_locales/es/cli/run.mdx b/_locales/es/cli/run.mdx new file mode 100644 index 0000000..52b5d93 --- /dev/null +++ b/_locales/es/cli/run.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard run ejecuta un comando en tu máquina con el proyecto de un servicio y los secretos del servicio inyectados. Incluye cuándo usar ssh en su lugar." +--- + +# lizard run + +Ejecuta un comando localmente con los secretos del proyecto y del servicio inyectados. + +## run vs. ssh + +Dos comandos te permiten ejecutar comandos con el contexto de un servicio. Se ejecutan en lugares distintos — asegúrate de usar el que necesitas. + +| Comando | Dónde se ejecuta | Usar para | +|---------|-----------|---------| +| `lizard run` | Localmente, con los secretos del proyecto + servicio del servicio inyectados | Migraciones, scripts de seed, herramientas locales que necesitan configuración de prod | +| `lizard ssh` | Dentro del contenedor del servicio en ejecución | Inspeccionar el contenedor en vivo, comandos remotos puntuales, depuración | + +`lizard run` muestra tu copia local inyectada del entorno, que normalmente es la misma que ve la app en ejecución — pero `lizard ssh` es la referencia autoritativa para el contenedor en vivo. Para comprobar lo que realmente ve la app en ejecución, usa `lizard ssh` en su lugar. + + + +## Uso + +```bash +lizard run [flags] -- +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-s, --service ` | Servicio cuyo env se debe inyectar | +| `--no-service` | No inyectar el env del servicio | + + + +## Ejemplos + + + +### Ejecutar una migración con los secretos del servicio inyectados + +```bash +lizard run --service api -- node scripts/migrate.js +``` + + + +### Imprimir una variable de entorno inyectada + +```bash +lizard run --service api -- printenv DATABASE_URL +``` + + + +## Ver también + +- [lizard ssh](/cli/ssh) — ejecuta un comando dentro del contenedor del servicio en ejecución en lugar de hacerlo localmente +- [Variables](/variables) — cómo se definen y se referencian las variables del proyecto y del servicio +- [Alojamiento de apps en Python](https://lizard.build/blog/python-app-hosting) — ejecutar `manage.py` y otras herramientas del framework contra una base de datos desplegada diff --git a/_locales/es/cli/scale.mdx b/_locales/es/cli/scale.mdx new file mode 100644 index 0000000..4085017 --- /dev/null +++ b/_locales/es/cli/scale.mdx @@ -0,0 +1,67 @@ +--- +description: "lizard scale cambia las réplicas, CPU y memoria de un servicio, y aumenta el almacenamiento de un addon. Valores permitidos y ejemplos para cada flag." +--- + +# lizard scale + +Escala un servicio (réplicas / CPU / memoria / almacenamiento). + + + +## Uso + +```bash +lizard scale [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `--replicas ` | Réplicas `1`–`10` (apps) | +| `--cpu ` | `1`, `2`, `3` o `4` | +| `--memory ` | `128`–`8192` MB | +| `--storage ` | Tamaño del volumen del addon, solo ampliable | + + + +## Ejemplos + + + +### Escalar réplicas horizontalmente + +```bash +lizard scale --service api --replicas 5 +``` + +Cada réplica es su propio pod detrás del balanceador de carga. Asegúrate de que tu app sea sin estado para que las réplicas sean intercambiables. + + + +### Escalar CPU y memoria verticalmente + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +### Ampliar el almacenamiento del addon + +```bash +lizard scale --service postgres --storage 8192 +``` + +Los volúmenes de datos del addon son solo ampliables: puedes aumentar el almacenamiento, pero no reducirlo. + + + +## Véase también + +- [Escalado](/deploy/scaling) — escalado horizontal vs. vertical y ampliación del almacenamiento del addon +- [lizard metrics](/cli/metrics) — consulta CPU / memoria / red / disco antes y después del escalado +- [lizard ps](/cli/ps) — comprueba el estado de las réplicas después de un cambio de escala +- [Observabilidad → Métricas](/observability/metrics) — monitorización de recursos y costos diff --git a/_locales/es/cli/secrets.mdx b/_locales/es/cli/secrets.mdx new file mode 100644 index 0000000..25361cb --- /dev/null +++ b/_locales/es/cli/secrets.mdx @@ -0,0 +1,100 @@ +--- +description: "lizard secrets establece, lista, elimina e importa variables de entorno en el ámbito del servicio o del proyecto, incluida la importación de dotenv desde stdin." +--- + +# lizard secrets + +Gestiona los secretos (variables de entorno) de un proyecto o servicio. + + + +## Uso + +```bash +lizard secrets [args] [flags] +``` + + + +## Subcomandos + +### `lizard secrets set ...` + +Establece uno o más secretos (variádico). El ámbito predeterminado es el servicio; `--global` apunta al proyecto. + +| Bandera | Descripción | +|------|-------------| +| `--global` | Ámbito del proyecto | +| `-s, --service ` | Ámbito del servicio | + +### `lizard secrets list` + +Lista los secretos del ámbito. + +| Bandera | Descripción | +|------|-------------| +| `--show` | Mostrar valores | +| `--ref` | Mostrar referencias | + +### `lizard secrets delete ...` + +Elimina uno o más secretos (variádico). + +### `lizard secrets import` + +Importa un archivo dotenv desde stdin. + + + +## Ejemplos + + + +### Establecer secretos en el servicio vinculado + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + + + +### Establecer un secreto para todo el proyecto + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +### Listar y mostrar secretos + +```bash +lizard secrets list +lizard secrets list --show +``` + + + +### Eliminar secretos + +```bash +lizard secrets delete OLD_KEY ANOTHER_KEY +``` + + + +### Importar un archivo dotenv + +```bash +cat .env | lizard secrets import +``` + + + +## Véase también + +- [Variables y secretos](/variables) — ámbito, precedencia y comportamiento en tiempo de compilación frente a tiempo de ejecución +- [Referencias entre servicios](/variables/references) — leer los valores de un servicio desde otro +- [Solución de problemas: un secreto o una referencia no aparece](/variables/troubleshooting/reference-not-applied) +- [lizard run](/cli/run) — ejecutar un comando localmente con los secretos del proyecto y del servicio inyectados diff --git a/_locales/es/cli/service.mdx b/_locales/es/cli/service.mdx new file mode 100644 index 0000000..f7fc39d --- /dev/null +++ b/_locales/es/cli/service.mdx @@ -0,0 +1,95 @@ +--- +description: "lizard service lee y edita la configuración de compilación, inicio, origen y variables de un servicio, y gestiona el cambio de nombre, la eliminación, los registros y la vinculación." +--- + +# lizard service + +Administra la configuración, el origen y el ciclo de vida de un servicio individual. + + + +## Uso + +```bash +lizard service set [flags] +lizard service show [flags] +lizard service rename +lizard service delete [flags] +lizard service logs +lizard service link +``` + + + +## Subcomandos + +### `lizard service set` + +Aplica cambios de compilación/inicio/origen/variables/cambio de nombre a un servicio. + +| Bandera | Descripción | +|------|-------------| +| `--set =` | Establece un campo (repetible) | +| `-f, --file ` | Archivo de configuración JSON para aplicar | +| `--force` | Sobrescribe incluso si cambió de forma remota | + +Los campos comunes son planos y se asignan 1:1 al esquema wire: `sourceType`, `repoUrl`, `branch`, `rootDirectory`, `dockerfilePath`, `buildCommand`, `startCommand`, `preDeployCommand`, `watchPatterns`, `containerPort`, `name`. + +`service set` usa concurrencia optimista mediante `configRevision`. Ante un `409`, vuelve a leer la configuración con `lizard service show`, reconcilia y reintenta, o pasa `--force`. + +### `lizard service show` + +Muestra la configuración actual del servicio como JSON. Usa `-s` para limitarlo a un servicio. + +### `lizard service rename` + +Cambia el nombre de un servicio o addon. Las referencias a este (`${{name.KEY}}`) permanecen estables. + +### `lizard service delete` + +Elimina un servicio. `-y, --yes` omite la confirmación. + +### `lizard service logs` + +Transmite los registros de un servicio (consulta también [lizard logs](/cli/logs)). + +### `lizard service link` + +Vincula un servicio al directorio actual. + + + +## Ejemplos + + + +### Actualizar los comandos de compilación e inicio de un servicio + +```bash +lizard service set api --set branch=main --set buildCommand="npm run build" +``` + + + +### Inspeccionar la configuración completa de un servicio + +```bash +lizard service show -s api +``` + + + +### Eliminar un servicio sin un aviso de confirmación + +```bash +lizard service delete -y +``` + + + +## Véase también + +- [lizard port](/cli/port) — muestra o cambia el puerto del contenedor de un servicio +- [lizard scale](/cli/scale) — escala las réplicas, CPU, memoria o almacenamiento de un servicio +- [Architecture](/concepts/architecture) — cómo se relacionan los servicios con los proyectos y los addons +- [Compilar pipeline](/concepts/build-pipeline) — cómo se usan `buildCommand`, `startCommand` y la configuración de origen en tiempo de compilación diff --git a/_locales/es/cli/skills.mdx b/_locales/es/cli/skills.mdx new file mode 100644 index 0000000..c4b3678 --- /dev/null +++ b/_locales/es/cli/skills.mdx @@ -0,0 +1,61 @@ +--- +description: "lizard skills lee las guías para agentes incluidas con tu versión de CLI, para que un agente de IA siempre reciba instrucciones que coincidan con el binario." +--- + +# lizard skills + +Lee las skills para agentes integradas que se incluyen con esta versión de CLI. + + + +## Uso + +```bash +lizard skills list +lizard skills get core +lizard skills path +``` + + + +## Subcomandos + +### `lizard skills list` + +Lista las skills integradas disponibles. + +### `lizard skills get core` + +Lee la guía principal — la guía de uso autorizada para la plataforma, versionada junto con la CLI. Devuelve `{ name, frontmatter, content, … }`, donde `content` es la guía completa (pipeline de build, precedencia de env, addons, discovery, códigos de salida). + +### `lizard skills path` + +Muestra dónde se almacenan las skills en el disco. + + + +## Ejemplos + + + +### Cargar la guía principal como agente + +```bash +lizard skills get core --json +``` + + + +### Listar las skills integradas disponibles + +```bash +lizard skills list +``` + + + +## Véase también + +- [AI agents & MCP](/agents) — cómo los agentes se inicializan con la skill integrada y comandos autodescriptivos +- [JSON & automation](/cli/json) — el formato de salida `--json` usado por `lizard skills get core --json` +- [Desplegar desde Claude Code](https://lizard.build/blog/deploy-from-claude-code) — instalar la skill y entregar el deploy al agente, de punta a punta diff --git a/_locales/es/cli/ssh.mdx b/_locales/es/cli/ssh.mdx new file mode 100644 index 0000000..8cf41ac --- /dev/null +++ b/_locales/es/cli/ssh.mdx @@ -0,0 +1,70 @@ +--- +description: "lizard ssh ejecuta un comando dentro del contenedor de un servicio en vivo y devuelve su código de salida. La forma autorizada de ver lo que ve el contenedor." +--- + +# lizard ssh + +Ejecuta un comando dentro del contenedor de un servicio en ejecución, transmite su salida y devuelve el código de salida remoto. + +## run vs. ssh + +`lizard run` y `lizard ssh` ejecutan un comando con el contexto de un servicio, pero se ejecutan en lugares distintos — conviene saber cuál quieres. + +| Comando | Dónde se ejecuta | Usar para | +|---------|-----------|---------| +| `lizard run` | **Localmente**, con el proyecto del servicio + los secretos del servicio inyectados | Migraciones, scripts de seed, herramientas locales que necesitan configuración de prod | +| `lizard ssh` | **Dentro del contenedor del servicio en ejecución** | Inspeccionar el contenedor en vivo, comandos remotos puntuales, depuración | + +`lizard run` muestra tu copia local inyectada del entorno, que normalmente es la misma que producción — pero `lizard ssh` es la referencia autorizada de lo que realmente ve el contenedor en vivo. + + + +## Uso + +```bash +lizard ssh --service -- +``` + + + +## Ejemplos + + + +### Inspeccionar el entorno que ve la app en ejecución + +```bash +lizard ssh --service api -- env +``` + + + +### Listar archivos en la imagen desplegada + +```bash +lizard ssh --service api -- ls -la /app +``` + + + +### Comprobar el sistema operativo en el contenedor + +```bash +lizard ssh --service api -- cat /etc/os-release +``` + + + +### Confirmar que un secreto llegó al contenedor en vivo + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## Véase también + +- [lizard run](/cli/run) — ejecuta un comando localmente con el entorno del servicio inyectado en su lugar +- [Variables](/variables) — cómo llegan los secretos y las referencias a un servicio +- [Desplegar desde Claude Code](https://lizard.build/blog/deploy-from-claude-code#claude-code-deployment-compared-with-the-alternatives) — por qué un agente necesita una shell dentro del contenedor en ejecución, y qué plataformas no ofrecen una diff --git a/_locales/es/cli/status.mdx b/_locales/es/cli/status.mdx new file mode 100644 index 0000000..584fca2 --- /dev/null +++ b/_locales/es/cli/status.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard status muestra a qué espacio de trabajo, proyecto y servicio está vinculado el directorio actual, antes de que despliegues en el equivocado." +--- + +# lizard status + +Muestra el espacio de trabajo, proyecto y servicio vinculados al directorio actual. + + + +## Uso + +```bash +lizard status +``` + + + +## Ejemplos + + + +### Verificar el vínculo del directorio actual + +```bash +lizard status +``` + + + +## Ver también + +- [lizard init](/cli/init) — crear o seleccionar un proyecto y vincularlo al directorio actual +- [lizard link](/cli/link) — asociar el directorio actual con un proyecto existente +- [lizard whoami](/cli/whoami) — mostrar el usuario actual, el espacio de trabajo activo y el proyecto vinculado diff --git a/_locales/es/cli/unlink.mdx b/_locales/es/cli/unlink.mdx new file mode 100644 index 0000000..b1f9501 --- /dev/null +++ b/_locales/es/cli/unlink.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard unlink elimina el vínculo entre el directorio actual y cualquier proyecto, sin afectar al proyecto en sí." +--- + +# lizard unlink + +Desvincula el directorio actual de cualquier proyecto. + + + +## Uso + +```bash +lizard unlink +``` + + + +## Ejemplos + + + +### Desvincular el directorio actual + +```bash +lizard unlink +``` + + + +## Véase también + +- [lizard link](/cli/link) — asociar el directorio actual con un proyecto +- [lizard status](/cli/status) — comprobar el espacio de trabajo, proyecto y servicio vinculados diff --git a/_locales/es/cli/up.mdx b/_locales/es/cli/up.mdx new file mode 100644 index 0000000..1907825 --- /dev/null +++ b/_locales/es/cli/up.mdx @@ -0,0 +1,88 @@ +--- +description: "lizard up empaqueta el directorio actual, lo compila en los nodos de compilación de Lizard y devuelve una URL activa. Banderas, comportamiento en CI y ejemplos." +--- + +# lizard up + +Sube el directorio actual y lo despliega. + + + +## Uso + +```bash +lizard up [flags] +``` + +`up` empaqueta tu árbol de trabajo como un tarball, lo envía a los nodos de compilación y lo despliega. Fuerza `sourceType=upload` en el servicio de destino, transmite los logs de compilación por SSE e imprime la URL activa al terminar. + +Si el directorio actual todavía no está vinculado a un proyecto, `up` ejecuta primero `init`. En un TTY eso es interactivo; en un entorno sin TTY (CI) **no** creará un proyecto silenciosamente: devolverá un error y te pedirá que ejecutes `lizard init --name ` (o que pases `--name`), para evitar que un error tipográfico genere un proyecto vacío. + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `-s, --service ` | Apunta a un servicio existente | +| `--build-command ` | Sobrescribe el comando de compilación | +| `--start-command ` | Sobrescribe el comando de inicio | +| `--pre-deploy-command ` | Se ejecuta una vez antes de cada despliegue | +| `--port ` | Puerto del contenedor (`0` = modo worker) | +| `--region ` | Región donde desplegar | +| `-d, --detach` | Inicia el despliegue y sale sin transmitir logs | +| `-c, --ci` | Salida compatible con CI | +| `--no-gitignore` | Sube todo, ignorando `.gitignore` | + + + +## Subcomandos + +### `lizard up status` + +Informa el estado de un despliegue por subida en curso. + + + +## Ejemplos + + + +### Desplegar el directorio actual + +```bash +lizard up +``` + + + +### Desplegar en un servicio específico con un comando de inicio y un puerto personalizados + +Crea primero el servicio con nombre con `lizard add --service api` si no existe. + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +### Desplegar sin interacción en CI + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard add --service api +lizard up --ci --service api +``` + +Omite `lizard add` cuando el servicio ya exista. Con Lizard CLI 0.3.92, una compilación fallida todavía puede salir con el código `0`; inspecciona el estado de la compilación y la URL desplegada antes de marcar una versión de CI como exitosa. Hay una corrección pendiente de publicación. En macOS, también configura `COPYFILE_DISABLE=1` antes de una subida para evitar archivos de metadatos adicionales de `._*` en el archivo. Consulta [framework setup](/framework-guides#prepare-the-project). + + + +## Véase también + +- [Desplegar desde código local](/deploy/upload) — guía completa de los despliegues basados en subida +- [lizard redeploy](/cli/redeploy) — vuelve a compilar la última subida sin volver a subirla +- [lizard init](/cli/init) — crea o vincula un proyecto explícitamente antes de desplegar +- [Worker services](/deploy/workers) — qué significa `--port 0` +- [Desplegar un contenedor sin configurar uno](https://lizard.build/blog/container-as-a-service#deploy-a-container-without-configuring-one) — dónde se ubica este comando entre las plataformas de contenedor como servicio diff --git a/_locales/es/cli/upgrade.mdx b/_locales/es/cli/upgrade.mdx new file mode 100644 index 0000000..a51a805 --- /dev/null +++ b/_locales/es/cli/upgrade.mdx @@ -0,0 +1,50 @@ +--- +description: "lizard upgrade actualiza la CLI en el lugar, o comprueba si hay una versión más reciente sin instalarla con --check." +--- + +# lizard upgrade + +Actualiza la CLI a la versión más reciente. + + + +## Uso + +```bash +lizard upgrade [flags] +``` + + + +## Banderas + +| Bandera | Descripción | +|------|-------------| +| `--check` | Comprueba si hay una versión más reciente sin instalarla | + + + +## Ejemplos + + + +### Actualizar a la versión más reciente + +```bash +lizard upgrade +``` + + + +### Comprobar actualizaciones sin instalar + +```bash +lizard upgrade --check +``` + + + +## Véase también + +- [Referencia de la CLI](/cli) — instalación, flags globales, códigos de salida +- [Primeros pasos](/getting-started) — instalar la CLI por primera vez diff --git a/_locales/es/cli/whoami.mdx b/_locales/es/cli/whoami.mdx new file mode 100644 index 0000000..9d1c7f3 --- /dev/null +++ b/_locales/es/cli/whoami.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard whoami imprime la cuenta con la que has iniciado sesión, tu espacio de trabajo activo y el proyecto vinculado a este directorio." +--- + +# lizard whoami + +Muestra el usuario actual, el espacio de trabajo activo y el proyecto vinculado. + + + +## Uso + +```bash +lizard whoami +``` + + + +## Ejemplos + + + +### Comprueba con qué cuenta has iniciado sesión + +```bash +lizard whoami +``` + + + +## Véase también + +- [lizard login](/cli/login) — autentícate antes de comprobar tu identidad +- [lizard status](/cli/status) — muestra el espacio de trabajo, proyecto y servicio vinculados para el directorio actual +- [lizard workspace](/cli/workspace) — enumera los espacios de trabajo a los que puedes acceder diff --git a/_locales/es/cli/workspace.mdx b/_locales/es/cli/workspace.mdx new file mode 100644 index 0000000..f3c4c47 --- /dev/null +++ b/_locales/es/cli/workspace.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard workspace list muestra todos los workspaces a los que tu cuenta puede acceder y cómo los workspaces se relacionan con los proyectos y los servicios." +--- + +# lizard workspace + +Lista los workspaces a los que puedes acceder. + + + +## Uso + +```bash +lizard workspace list +``` + + + +## Ejemplos + + + +### Lista tus workspaces + +```bash +lizard workspace list +``` + + + +## Véase también + +- [lizard whoami](/cli/whoami) — muestra tu workspace activo +- [Architecture: Espacio de trabajo](/concepts/architecture) — cómo los workspaces se relacionan con los proyectos y los servicios diff --git a/_locales/es/concepts/_meta.ts b/_locales/es/concepts/_meta.ts new file mode 100644 index 0000000..ceec0b0 --- /dev/null +++ b/_locales/es/concepts/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Resumen", + architecture: "Arquitectura", + 'build-pipeline': "Pipeline de compilación", + deployments: "Despliegues", +}; diff --git a/_locales/es/concepts/architecture.mdx b/_locales/es/concepts/architecture.mdx new file mode 100644 index 0000000..fc7a84e --- /dev/null +++ b/_locales/es/concepts/architecture.mdx @@ -0,0 +1,126 @@ +--- +description: "Cómo Lizard organiza el trabajo en workspaces, proyectos y servicios, además de addons gestionados, referencias entre recursos y variables inyectadas." +--- + + + +# Arquitectura + +Lizard organiza todo lo que despliegas en una jerarquía de tres niveles, además de addons gestionados que se adjuntan a un proyecto. + +``` +workspace +└── project + ├── service (app) ← built from GitHub or an upload + ├── service (worker) ← background job, no HTTP port + └── addons + ├── postgres + ├── redis + └── s3 +``` + + + +## Espacio de trabajo + +Un **workspace** es el nivel de cuenta u organización. Perteneces al menos a uno, y la facturación, los miembros y los proyectos dependen de él. Lista los que puedes acceder: + +```bash +lizard workspace list +lizard whoami # shows your active workspace +``` + +Muchos comandos aceptan `-w, --workspace ` para desambiguar cuando el mismo nombre de proyecto existe en más de un workspace. + + + +## Proyecto + +Un **proyecto** agrupa servicios y addons relacionados dentro de un workspace. Tu directorio de trabajo queda *vinculado* a un proyecto, y ese vínculo (almacenado en `~/.lizard/config.json`) es como la CLI sabe a qué estás apuntando. + +```bash +lizard init --name my-project # create or select a project, link the cwd +lizard link --project my-project # link to an existing project +lizard status # show the current directory's link +lizard unlink # remove the link +lizard project list # all projects in the workspace +``` + +> **Consejo:** Usa el nombre del repositorio o del directorio para el proyecto, y nombres de tipo app (`api`, `worker`, `web`) para los servicios. + + + +## Servicio + +Un **servicio** es una sola unidad desplegable. Su origen es uno de estos: + +- **`github`** — un repositorio de GitHub conectado. Los pushes a la rama seguida vuelven a desplegar automáticamente. +- **`upload`** — un tarball subido con `lizard up`. + +Cada servicio en ejecución corre como su propio **pod aislado** con una política de red de denegación por defecto, un dominio `..onlizard.com` generado y TLS automático. Esa separación — tú aportas el contenedor, la plataforma lo ejecuta — es [container as a service](https://lizard.build/blog/container-as-a-service), y el blog explica de qué sigues teniendo que ocuparte. Inspecciona y gestiona servicios con: + +```bash +lizard ps # list services with status + URL +lizard service show # full config as JSON +lizard service set --set = +lizard service rename --service +lizard service delete --service +``` + +Los campos de configuración del servicio son **planos** y se asignan 1:1 al esquema en el wire (p. ej. `repoUrl`, `branch`, `buildCommand`, `startCommand`, `containerPort`, `rootDirectory`). No existe anidamiento de `build.*` / `deploy.*`. Consulta [`lizard service`](/cli/service) para ver la lista completa. + + + +### Servicios app vs. worker + +Por defecto, un servicio es una **app HTTP** que escucha en un puerto (`3000` por defecto) y se sirve en su dominio. Un servicio que no escucha en un puerto — un consumidor de colas, reconciliador o bucle de sondeo — debe ejecutarse en [**modo worker**](/deploy/workers) configurando `containerPort=0`. Los workers omiten la inyección de puerto, la comprobación de salud de accesibilidad y el registro en el balanceador de carga. + + + +## Addons gestionados + +Los **addons** son Postgres, Redis y almacenamiento compatible con S3 gestionados que aprovisionas por proyecto: + +```bash +lizard add postgres redis s3 +``` + +Cada addon expone un conjunto fijo de variables de entorno que tus servicios consumen por **referencia** (`${{.KEY}}`). Consulta [Managed Addons](/addons). + + + +## Referencias entre recursos + +Cualquier valor de un servicio o addon puede referenciarse desde el entorno de otro recurso usando: + +``` +${{.}} +``` + +Las referencias se resuelven en **tiempo de despliegue** contra el entorno combinado del destino. Se almacenan por ID, así que renombrar el destino después no rompe la referencia. Una referencia a un destino o clave inexistente se resuelve como una cadena vacía (el despliegue **no** falla por eso); solo las referencias circulares lanzan errores. + +```bash +# Wire a service to the project's Postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + +Verifica que el consumidor realmente recibió el valor: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## Variables inyectadas por la plataforma + +Cada servicio recibe automáticamente estas variables (no se pueden sobrescribir): + +| Variable | Descripción | +|----------|-------------| +| `PORT` | Puerto en el que tu app debe escuchar (se omite en modo worker) | +| `LIZARD_SERVICE_NAME` | El nombre del servicio | +| `LIZARD_PROJECT_ID` | El ID del proyecto | +| `LIZARD_PUBLIC_DOMAIN` | El dominio público del servicio | + +Consulta [Variables & Secrets](/variables) para ver cómo interactúan con tus propias variables y el orden completo de precedencia. diff --git a/_locales/es/concepts/build-pipeline.mdx b/_locales/es/concepts/build-pipeline.mdx new file mode 100644 index 0000000..cf5baef --- /dev/null +++ b/_locales/es/concepts/build-pipeline.mdx @@ -0,0 +1,89 @@ +--- +description: "Cómo Lizard convierte el código fuente en una imagen de contenedor: Dockerfile sintetizado, Dockerfile del repositorio o autodetección de lizardpack, y qué activa una reconstrucción." +--- + + + +# Canal de compilación + +Las compilaciones se ejecutan en los nodos de compilación de Lizard — **no necesitas Docker localmente**. Cuando despliegas, la plataforma decide cómo convertir tu código fuente en una imagen de contenedor usando un orden de decisión fijo, y luego ejecuta esa imagen en un pod aislado. No todos los [container as a service](https://lizard.build/blog/container-as-a-service) compilan la imagen por ti; el blog compara las tres formas en que se presenta esta categoría. + + + +## Orden de decisión de compilación + +La plataforma elige exactamente una estrategia de compilación, en este orden: + +1. **Dockerfile sintetizado** — si `buildCommand` y/o `startCommand` están configurados en el servicio (o se pasan mediante `lizard up --build-command` / `--start-command`), Lizard genera un Dockerfile a partir de esos comandos. lizardpack no se invoca. +2. **Dockerfile del repositorio (literal)** — si `dockerfilePath` está configurado en el servicio, ese Dockerfile de tu repositorio se usa sin cambios. +3. **Autodetección de lizardpack** — en caso contrario, la plataforma clona tu código fuente y ejecuta **lizardpack**, su generador de buildpacks/Dockerfile. + + + +### Autodetección de lizardpack + +lizardpack inspecciona tu repositorio y construye una imagen optimizada de múltiples etapas. Stacks compatibles, emparejados en este orden: + +**Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static** + +Consulta las [Guías de frameworks](/framework-guides) para ver scripts de producción, adaptadores, rutas de salida y puertos. La detección usa archivos del proyecto y dependencias; un repositorio que coincida con varios proveedores sigue este orden. + +En esta ruta: + +- Si existe un `Dockerfile` del repositorio **y** tiene un paso de compilación real (una línea `RUN `, no solo `COPY dist/`), se usa literalmente. +- En caso contrario, lizardpack genera el Dockerfile por ti. +- El **comando de inicio** se detecta automáticamente: una línea `Procfile` `web:` (Python/Ruby) o `package.json` `scripts.start` (Node) se recoge automáticamente. Para ver la línea exacta que quieren Django, Flask y FastAPI, consulta [hosting de aplicaciones Python](https://lizard.build/blog/python-app-hosting). +- El **puerto** se infiere a partir de `EXPOSE`, los valores predeterminados del framework o una variable de entorno `PORT` explícita. + +> **Ojo:** Un Dockerfile que solo copia artefactos ya compilados (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) **sin** un paso de compilación `RUN` se considera incompleto y lizardpack lo regenera. Añade un paso de compilación real o configura `dockerfilePath` para forzar el uso literal. + + + +## Qué activa una reconstrucción + +| Acción | ¿Reconstruye? | +|--------|-----------| +| `git push` en la rama seguida | ✅ mediante webhook de GitHub | +| `lizard redeploy` / `lizard up` | ✅ explícito | +| Cambiar variables `VITE_*` o `NEXT_PUBLIC_*` | ✅ los valores de tiempo de compilación se integran en la imagen | +| `service set` de campos de compilación (`repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath`, `rootDirectory`) | ✅ reconstruye automáticamente | +| `service set` de campos solo de runtime (`startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns`) | ❌ ejecuta `lizard redeploy` para aplicar | +| Cualquier otro cambio de variable de entorno / secreto | ❌ se aplica con un reinicio rápido (sin reconstrucción) | + +> **No compiles dos veces.** Después de un `service set` que cambia un campo de compilación, la reconstrucción se activa automáticamente — no encadenes un `lizard redeploy` después, o pondrás en cola una segunda compilación redundante. + + + +## Ver una compilación + +Los registros de compilación se transmiten durante `lizard up`. Para cualquier servicio: + +```bash +lizard logs --build # the most recent build's logs +lizard events # deploy history + replica status +``` + +Si una compilación falla, lee `lizard logs --build`, corrige la causa (en tu repositorio o ajustando `buildCommand` / `startCommand` mediante `lizard service set`) y luego `lizard redeploy`. + + + +## Notas de runtime + +- **Sin Docker `HEALTHCHECK`.** El runtime no ejecuta el ciclo de healthcheck de Docker, por lo que las directivas `HEALTHCHECK` se ignoran. Lizard ejecuta en su lugar una sonda TCP contra tu puerto (omitida en [modo worker](/deploy/workers)). +- **No escribas un Dockerfile sin necesidad.** lizardpack detecta automáticamente la mayoría de los stacks — prueba primero con un despliegue y añade un Dockerfile (o configura `dockerfilePath`) solo si la compilación automática no se ajusta a tu caso. + + + +## Referencia de configuración de compilación + +| Campo | Descripción | +|-------|-------------| +| `buildCommand` | Comando para compilar tu aplicación → fuerza la ruta de **Dockerfile sintetizado** | +| `startCommand` | Comando para iniciar tu aplicación en runtime | +| `preDeployCommand` | Se ejecuta una vez antes de cada despliegue (p. ej., migraciones de BD) | +| `dockerfilePath` | Ruta a un Dockerfile del repositorio para usar **literalmente** | +| `rootDirectory` | Subdirectorio desde el que compilar (monorepos) | +| `watchPatterns` | Solo redesplegar cuando cambien rutas coincidentes | +| `containerPort` | Puerto TCP en el que escucha tu aplicación (predeterminado `3000`; `0` = [worker](/deploy/workers)) | + +Configura cualquiera de estos con `lizard service set --set =`. Consulta [`lizard service`](/cli/service). diff --git a/_locales/es/concepts/deployments.mdx b/_locales/es/concepts/deployments.mdx new file mode 100644 index 0000000..73a8200 --- /dev/null +++ b/_locales/es/concepts/deployments.mdx @@ -0,0 +1,95 @@ +--- +description: "El ciclo de despliegue en Lizard: qué desencadena una compilación, cómo el tráfico cambia a réplicas en buen estado y en qué se diferencian los reinicios de los redespliegues." +--- + + + +# Despliegues + +Un **despliegue** es una compilación y publicación de un servicio. La ruta de publicación depende del entorno de ejecución del servicio. Una compilación correcta no demuestra por sí sola que la aplicación se haya iniciado o pueda atender solicitudes. + + + +## Cómo ocurre un despliegue + +Un despliegue se desencadena por cualquiera de estos casos: + +- Un **`git push`** a la rama seguida (para servicios con código fuente `github`). +- **`lizard redeploy`** — recompila desde el commit más reciente (git) o la última carga, con las variables actuales. +- **`lizard up`** — carga el directorio actual y lo despliega. +- Un **`service set`** que cambia un campo que afecta a la compilación. + +```bash +lizard redeploy --service api # rebuild + redeploy from current source +lizard up # upload cwd and deploy +``` + + + +## Ciclo de vida + +1. **Compilación** — la plataforma ejecuta tu compilación (consulta [Proceso de compilación](/concepts/build-pipeline)). +2. **Predeploy** — si `preDeployCommand` está configurado, se ejecuta una vez (por ejemplo, migraciones). +3. **Inicio** — Lizard inicia la aplicación para su entorno de ejecución configurado. +4. **Comprobación de estado** — la plataforma verifica que se pueda acceder al puerto de la app (se omite para [workers](/deploy/workers)). +5. **Verificación** — inspecciona el estado de la publicación y llama a la URL de la aplicación. La accesibilidad del puerto no es una comprobación completa del estado de la aplicación. + + + +## Salida en streaming + +Cuando ejecutas un `lizard up` no desacoplado (o `redeploy`), los registros de compilación se transmiten en vivo. Con `--json`, obtienes un evento JSON por línea: + +```json +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "...", "url": "https://..." } +``` + +que termina en `deployed`, `failed` o `deploying`. Usa `--detach` para iniciar el despliegue y volver inmediatamente sin transmitir la salida. + + + +## Inspección del historial + +```bash +lizard events # deploy history + per-replica status +lizard events --limit 25 # show more +lizard ps # current services, status, and URLs +``` + +En el [panel](/dashboard), la vista de **Despliegues** muestra la cronología completa, los registros de compilación de cada despliegue y un panel de detalles para cada publicación. + + + +## Reinicios vs. redespliegues + +| Comando | Qué hace | +|---------|--------------| +| `lizard restart --service ` | Reinicio de la compilación **actual** — sin recompilar | +| `lizard redeploy --service ` | **Compilación** nueva desde el último commit/carga, y luego publicación | + +Usa `restart` para reciclar réplicas (por ejemplo, para aplicar un secreto de ejecución que no se recargó en caliente); usa `redeploy` cuando necesites una nueva compilación. + + + +## Recuperación tras un fallo + +Inspecciona los registros del fallo o reinicio más reciente: + +```bash +lizard logs --restart latest # log tail around the latest restart +lizard logs --restart # a specific restart +lizard events # see replica status +``` + + + +## Cambios de configuración (sin recompilar) + +La mayoría de los cambios en variables de entorno y secretos se aplican sin recompilar: Lizard actualiza la configuración del servicio y lo reinicia, lo que tarda unos segundos. Los valores de tiempo de compilación (`VITE_*`, `NEXT_PUBLIC_*`) y los cambios en campos de compilación sí fuerzan una recompilación — consulta la [tabla de desencadenantes de recompilación](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Publicaciones fallidas y recuperación + +Una compilación fallida y un inicio fallido de la aplicación son casos distintos. No asumas que una publicación anterior sigue atendiendo tráfico en todos los entornos de ejecución. Inspecciona el servicio activo, los registros de compilación y los registros de ejecución. `lizard redeploy` vuelve a compilar el origen seleccionado; no es un comando para restaurar una compilación anterior. Revierte el commit del código fuente cuando sea necesario, desplíegalo y comprueba el resultado. Consulta [problemas conocidos](/platform/known-issues). diff --git a/_locales/es/concepts/index.mdx b/_locales/es/concepts/index.mdx new file mode 100644 index 0000000..fabaf8b --- /dev/null +++ b/_locales/es/concepts/index.mdx @@ -0,0 +1,19 @@ +--- +description: "El modelo central detrás de Lizard: cómo se organiza tu código, cómo se compila y cómo una versión llega a producción." +--- + + + +# Conceptos + +El modelo central detrás de Lizard: cómo se organiza tu código, cómo se compila y cómo una versión llega a producción. Lee esto una vez y el resto de la documentación tendrá sentido. + +Para ver el modelo un nivel más arriba — cómo se llama una plataforma que ejecuta tu contenedor por ti y en qué se diferencia de PaaS, FaaS e IaaS — lee [container as a service](https://lizard.build/blog/container-as-a-service) en el blog. + + + +## En esta sección + +- [Arquitectura](/concepts/architecture) — la jerarquía workspace → project → service, los addons gestionados y las referencias entre recursos. +- [Pipeline de compilación](/concepts/build-pipeline) — cómo el código fuente se convierte en una imagen de contenedor (Dockerfile sintetizado, Dockerfile del repositorio o autodetección de lizardpack) y qué activa una nueva compilación. +- [Despliegues](/concepts/deployments) — el ciclo de compilación y publicación, reinicios frente a redeploys, y cambios de configuración en vivo. diff --git a/_locales/es/dashboard.mdx b/_locales/es/dashboard.mdx new file mode 100644 index 0000000..059764a --- /dev/null +++ b/_locales/es/dashboard.mdx @@ -0,0 +1,94 @@ +--- +description: "Qué añade el panel de Lizard al CLI: estado de servicios, cronología de despliegues, logs en streaming, métricas, exploradores de datos, equipo y facturación." +--- + + + +# Panel de la app + +El panel de Lizard es el complemento visual del CLI. Todo lo que haces con `lizard …` se refleja aquí, además de lo que es más fácil con una interfaz — logs en streaming, gráficos, los exploradores de datos y la gestión de equipo/facturación. + +Si prefieres no abrir un terminal en absoluto, deja que el agente ejecute los comandos y observa el resultado aquí — la ruta de [desplegar una app Antigravity en producción](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command), que requiere dos prompts y nada escrito en un terminal. + +Ábrelo desde el CLI: + +```bash +lizard open # open the current project +lizard docs # open this documentation +``` + + + +## Qué hay en el panel + + + +### Servicios + +La vista principal del proyecto muestra cada servicio con su indicador de estado, dominio generado y un acceso rápido a logs, métricas, secretos y ajustes. Crea nuevos servicios (desde un repositorio de GitHub o vacío) directamente desde aquí. + + + +### Despliegues + +Una cronología de cada despliegue, con logs de compilación por despliegue y un panel de detalles (commit, estado, réplicas). Este es el equivalente visual de `lizard events` + `lizard logs --build`. + +### Logs + +Streaming en vivo de logs de ejecución y compilación con búsqueda y filtros por nivel — la contraparte en la interfaz de [`lizard logs`](/observability/logs). + + + +### Métricas y uso + +Gráficos de CPU, memoria, red y disco por servicio, además de una vista de **Uso** que desglosa el consumo y el coste en todo el proyecto. Refleja [`lizard metrics --cost`](/observability/metrics). + + + +### Variables y secretos + +Gestiona secretos con alcance de servicio y de proyecto, con valores ocultos y compatibilidad con referencias (`${{…}}`). Consulta [Variables y secretos](/variables). + + + +### Dominios + +Añade dominios personalizados, consulta registros DNS y sigue el estado de verificación y TLS. Consulta [Redes](/networking). + + + +### Exploradores de addons gestionados + +Cada addon incluye un explorador de datos: + +- **Postgres** — un editor SQL/de tablas para consultar y editar datos. +- **Redis** — un explorador de clave/valor. +- **S3** — un explorador de buckets y objetos con subida/descarga. + + + +### Integración con GitHub + +Conecta la GitHub App, elige repositorios y gestiona qué repositorios puede compilar Lizard. Consulta [Desplegar desde GitHub](/deploy/github). + + + +### Ajustes, equipo y facturación + +Ajustes del proyecto y del workspace, invitaciones de miembros y roles, uso de recursos, créditos de la cuenta y recarga automática opcional. Las cuentas estándar usan [pay as you go](/platform/billing) sin suscripción mensual. + + + +## CLI ↔ Panel + +| Tarea | CLI | Vista del panel | +|------|-----|----------------| +| Historial de despliegues | `lizard events` | Despliegues | +| Streaming de logs | `lizard logs` | Logs | +| Gráficos de recursos | `lizard metrics` | Métricas / Uso | +| Gestionar secretos | `lizard secrets` | Variables | +| Dominios personalizados | `lizard domain` | Dominios | +| Explorar Postgres/Redis/S3 | `lizard run` / `lizard ssh` | Exploradores de addons | +| Invitar a compañeros de equipo | — | Equipo / Ajustes | + +Usa lo que mejor se adapte al momento — operan sobre los mismos proyectos y servicios. diff --git a/_locales/es/deploy/_meta.ts b/_locales/es/deploy/_meta.ts new file mode 100644 index 0000000..ae8dd3b --- /dev/null +++ b/_locales/es/deploy/_meta.ts @@ -0,0 +1,9 @@ +export default { + index: "Resumen", + github: "Desplegar desde GitHub", + upload: "Desplegar desde código local", + workers: "Workers en segundo plano", + scaling: "Escalado", + regions: "Regiones", + troubleshooting: "Solución de problemas", +}; diff --git a/_locales/es/deploy/github.mdx b/_locales/es/deploy/github.mdx new file mode 100644 index 0000000..f7a19b3 --- /dev/null +++ b/_locales/es/deploy/github.mdx @@ -0,0 +1,98 @@ +--- +description: "Conecta un repositorio de GitHub para que cada push a la rama seguida haga build y redespliegue, incluyendo repositorios privados, cambio de ramas y monorepos." +--- + + + +# Desplegar desde GitHub + +Conectar un repositorio de GitHub es la forma recomendada de ejecutar una app en Lizard: cada push a la rama seguida hace build y redespliega automáticamente. + + + +## Crear un servicio desde un repositorio + +```bash +lizard add -r your-org/your-app +``` + +Esto crea un servicio con origen `github`, clona el repositorio, detecta automáticamente el stack ([lizardpack](/concepts/build-pipeline)), hace el build y devuelve una URL activa. Banderas útiles: + +| Bandera | Propósito | +|------|---------| +| `-r, --repo ` | Repositorio de origen | +| `-n, --name ` | Nombre del servicio (se usa en las referencias `${{name.KEY}}` y en el panel) | +| `-v, --variables ` | Inicializar una variable de entorno; repetible | +| `--region ` | Región donde desplegar | +| `--no-deploy` | Adjunta el repositorio pero omite el primer build | + + + +## Repositorios privados + +Conecta la GitHub App de Lizard una vez por cuenta para conceder acceso a repositorios privados: + +```bash +lizard git connect +lizard git status # show connection + repo status +``` + +También puedes conectar y gestionar el acceso a repositorios desde la página de **integración de GitHub** en el panel (`lizard open`). + + + +## Apuntar un servicio existente a un repositorio + +Para cambiar un servicio a un origen git (o cambiar el repositorio/rama): + +```bash +lizard service set api \ + --set sourceType=github \ + --set repoUrl=https://github.com/your-org/your-app \ + --set branch=main +``` + +Cambiar un campo de build activa automáticamente un rebuild — **no** encadenes un `redeploy` después. + +> **Nota:** `lizard up` siempre fuerza `sourceType=upload`. No lo uses para actualizar un servicio respaldado por git — haz push al remoto o usa `lizard redeploy` en su lugar. + + + +## Redespliegue automático en push + +Una vez que `repoUrl` está configurado, los push a la `branch` correspondiente redespliegan automáticamente mediante el webhook de GitHub. Para limitar qué push activan un redespliegue: + +- **`rootDirectory`** — solo hace build de un subdirectorio (monorepos). +- **`watchPatterns`** — solo redespliega cuando cambian rutas coincidentes. + +```bash +lizard service set api --set watchPatterns='apps/api/**,packages/**' +``` + + + +## Cambiar de rama + +```bash +lizard git checkout api staging # move the `api` service to the `staging` branch and redeploy +``` + +## Monorepos + +Para un repositorio que contiene varias apps, crea un servicio por app y configura su `rootDirectory` con la subruta: + +```bash +lizard add -r your-org/monorepo -n api +lizard service set api --set rootDirectory=apps/api +``` + +Si tu directorio actual es una subapp dentro de un repositorio cuyo directorio padre ya está vinculado, añade el servicio en el proyecto del padre y configura `rootDirectory` con la subruta del cwd. + + + +## Ver también + +- [Proceso de compilación](/concepts/build-pipeline) — cómo se detecta y se hace build de tu stack. +- [Desplegar desde código local](/deploy/upload) — cuando no tienes un remoto. +- [`lizard git`](/cli/git) — la referencia completa de comandos para `connect`, `status` y `checkout`. +- [Dónde desplegar una aplicación que construyó tu IDE de IA](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#where-to-deploy-an-app-your-ai-ide-built) — cómo apuntar esto a un repositorio que escribió un agente, y cuánto cuesta. diff --git a/_locales/es/deploy/index.mdx b/_locales/es/deploy/index.mdx new file mode 100644 index 0000000..738b966 --- /dev/null +++ b/_locales/es/deploy/index.mdx @@ -0,0 +1,22 @@ +--- +description: "Todo sobre poner un servicio en funcionamiento en Lizard y mantenerlo allí: despliegues desde GitHub y localmente, workers, escalado, regiones y soluciones." +--- + + + +# Despliegue + +Todo sobre poner un servicio en funcionamiento en Lizard y mantenerlo así — desde tu primer push hasta el escalado y la ubicación por región. + +¿Primero lo estás comparando con otro host? El blog pone lado a lado los precios de nueve plataformas de [container as a service](https://lizard.build/blog/container-as-a-service). + + + +## En esta sección + +- [Desplegar desde GitHub](/deploy/github) — conecta un repositorio para que los pushes a la rama supervisada vuelvan a desplegarse automáticamente. +- [Desplegar desde código local](/deploy/upload) — publica el directorio actual con `lizard up`, sin necesidad de Git. +- [Workers en segundo plano](/deploy/workers) — ejecuta consumidores de colas y bucles de sondeo con `containerPort=0`. +- [Escalado](/deploy/scaling) — ajusta réplicas, recursos y almacenamiento. +- [Regiones](/deploy/regions) — dónde se ejecutan tus servicios. +- [Solución de problemas](/deploy/troubleshooting/incomplete-dockerfile) — soluciones para los problemas de compilación y despliegue más comunes. diff --git a/_locales/es/deploy/regions.mdx b/_locales/es/deploy/regions.mdx new file mode 100644 index 0000000..0a1bc1a --- /dev/null +++ b/_locales/es/deploy/regions.mdx @@ -0,0 +1,40 @@ +--- +description: "Elige dónde se ejecutan tus servicios y addons, ubica juntos los recursos con estado para reducir la latencia y observa cómo la región afecta a los dominios generados." +--- + + + +# Regiones + +Los servicios y addons se aprovisionan en una región. Lista las regiones disponibles para tu cuenta y elige una al crear. + + + +## Listar regiones + +```bash +lizard regions +lizard regions --json +``` + + + +## Elegir una región + +Pasa `--region ` al crear un servicio o addon: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +Si no especificas una región, la plataforma usa la predeterminada del proyecto. + +> **Ubica juntos los recursos con estado.** Coloca un servicio y los addons con los que se comunica (Postgres, Redis, S3) en la **misma región** para mantener baja la latencia y evitar cargos por datos entre regiones. + + + +## Dominios generados + +Cada servicio recibe un dominio generado en `*.onlizard.com` con TLS automático, independientemente de la región. El almacenamiento de objetos servido desde un [addon de S3](/addons/storage) usa un host de gateway con alcance regional (`s3-.onlizard.com`). Para asociar tu propio nombre de host, consulta [Networking](/networking). diff --git a/_locales/es/deploy/scaling.mdx b/_locales/es/deploy/scaling.mdx new file mode 100644 index 0000000..2eaeb59 --- /dev/null +++ b/_locales/es/deploy/scaling.mdx @@ -0,0 +1,78 @@ +--- +description: "Añade réplicas o aumenta la CPU y la memoria de un servicio, y amplía el almacenamiento de los addons. Rangos permitidos, comportamiento del despliegue y cómo verificar un cambio." +--- + + + +# Escalado + +Escala un servicio horizontalmente (más réplicas) o verticalmente (más CPU/memoria) con `lizard scale`. El almacenamiento de addons se amplía de la misma forma. + + + +## Escalar un servicio + +```bash +lizard scale --service api --replicas 3 +lizard scale --service api --cpu 2 --memory 2048 +``` + +| Bandera | Se aplica a | Valores permitidos | +|------|-----------|----------------| +| `--replicas ` | apps | `1`–`10` | +| `--cpu ` | apps | núcleos completos: `1`, `2`, `3`, `4` | +| `--memory ` | apps | `128`–`8192` MB (pasos de 1 MB) | +| `--storage ` | **solo addons**, solo ampliación | `512`, `1024`, `2048`, `4096`, `8192`, `16384` | + +Puedes combinar flags en un solo comando. Los cambios de réplicas se aplican sin reconstrucción. + + + +## Escalado horizontal + +Ejecuta varias réplicas de una app detrás del balanceador de carga: + +```bash +lizard scale --service api --replicas 5 +``` + +Cada réplica es su propio pod. Asegúrate de que tu app sea sin estado (guarda el estado en [Postgres](/addons/postgres), [Redis](/addons/redis) o [S3](/addons/storage)) para que las réplicas sean intercambiables. + + + +## Escalado vertical + +Asigna más recursos a una sola réplica: + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +## Ampliar el almacenamiento de addons + +Los volúmenes de datos de addons son **solo ampliación**: puedes aumentar el almacenamiento, pero no reducirlo: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Verificación + +```bash +lizard ps # replica status + URL +lizard events # per-replica deploy/scale history +lizard metrics # live CPU / memory / network / disk +lizard metrics --cost # include cost +``` + + + +## Ver también + +- [Observabilidad → Métricas](/observability/metrics) — supervisión de recursos y costes. +- [`lizard scale`](/cli/scale) — la referencia completa de comandos. +- [Qué cobran los proveedores de CaaS en 2026](https://lizard.build/blog/container-as-a-service#what-caas-providers-charge-in-2026) — tarifas por vCPU, por GB y de salida en nueve plataformas, para calcular una factura antes de escalar. diff --git a/_locales/es/deploy/troubleshooting/_meta.ts b/_locales/es/deploy/troubleshooting/_meta.ts new file mode 100644 index 0000000..9c02027 --- /dev/null +++ b/_locales/es/deploy/troubleshooting/_meta.ts @@ -0,0 +1,5 @@ +export default { + 'incomplete-dockerfile': "Los cambios en Dockerfile no se aplican", + 'double-build': "Un cambio puso dos compilaciones en cola", + 'service-never-healthy': "El servicio nunca llega a estar saludable", +}; diff --git a/_locales/es/deploy/troubleshooting/double-build.mdx b/_locales/es/deploy/troubleshooting/double-build.mdx new file mode 100644 index 0000000..2211b16 --- /dev/null +++ b/_locales/es/deploy/troubleshooting/double-build.mdx @@ -0,0 +1,53 @@ +--- +description: "Por qué lizard service set seguido de un redeploy pone en cola dos builds, qué campos reconstruyen por sí solos y cómo detener el redundante." +--- + + + +# Mi cambio puso en cola dos builds seguidos + +Ejecutaste `lizard service set` para cambiar un campo, luego `lizard redeploy`, y terminaste con dos builds en lugar de uno. + + + +## Qué significa esto + +La llamada `service set` ya activó una reconstrucción por sí sola. El `redeploy` posterior puso en cola una segunda reconstrucción redundante. + + + +## Por qué puede pasar esto + +Cambiar un campo que **afecta al build** en un servicio — `repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath` o `rootDirectory` — activa una reconstrucción automática de inmediato. Cambiar un campo **solo de runtime** — `startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns` — **no** activa una reconstrucción automática; solo surte efecto en el siguiente deploy. + +Es fácil encadenar por reflejo un `redeploy` después de cada `service set`, pero eso solo tiene sentido para los campos solo de runtime. + + + +## Posibles soluciones + + + +### Comprueba qué tipo de campo cambiaste + +Consulta la [tabla de activadores de reconstrucción](/concepts/build-pipeline#what-triggers-a-rebuild). Si es un campo de build, la reconstrucción ya está en cola; no hagas nada más. + +```bash +lizard events # confirm only one build is in flight +``` + + + +### Solo vuelve a desplegar después de cambios solo de runtime + +```bash +lizard service set api --set startCommand="node server.js" +lizard redeploy --service api # needed here — startCommand doesn't auto-rebuild +``` + + + +## Ver también + +- [Pipeline de build → qué activa una reconstrucción](/concepts/build-pipeline#what-triggers-a-rebuild) +- [`lizard service`](/cli/service) — la referencia completa de comandos. diff --git a/_locales/es/deploy/troubleshooting/incomplete-dockerfile.mdx b/_locales/es/deploy/troubleshooting/incomplete-dockerfile.mdx new file mode 100644 index 0000000..58da516 --- /dev/null +++ b/_locales/es/deploy/troubleshooting/incomplete-dockerfile.mdx @@ -0,0 +1,57 @@ +--- +description: "Por qué Lizard reemplaza un Dockerfile del repositorio que no tiene paso de compilación, cómo funciona la regla de Dockerfile incompleto y cómo hacer que se use el tuyo literalmente." +--- + + + +# Mis cambios en el Dockerfile no parecen aplicarse + +Tienes un `Dockerfile` en tu repositorio, lo editaste, pero la compilación que ejecuta Lizard no coincide con lo que escribiste. + + + +## Qué significa esto + +La plataforma decidió que el Dockerfile de tu repositorio estaba **incompleto** y regeneró uno por ti con [lizardpack](/concepts/build-pipeline) en lugar de usar el tuyo literalmente. + + + +## Por qué puede pasar esto + +Lizard solo usa un Dockerfile del repositorio **literalmente** en la ruta de autodetección de lizardpack si tiene un paso de compilación real: una línea `RUN `. Un Dockerfile que solo copia artefactos precompilados (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) sin un paso `RUN` se trata como incompleto, asumiendo que esos artefactos se compilaron fuera de la imagen. En ese caso, lizardpack genera un Dockerfile de reemplazo que incluye el paso de compilación faltante. + +Esto solo se aplica en la ruta de autodetección de lizardpack. Si `buildCommand` o `startCommand` está configurado en el servicio, Lizard sintetiza un Dockerfile a partir de esos comandos y no mira en absoluto el Dockerfile de tu repositorio. + + + +## Posibles soluciones + + + +### Agrega un paso de compilación real + +Si quieres que tu Dockerfile se use tal cual, dale un paso de compilación real en lugar de copiar salida precompilada: + +```dockerfile +RUN npm ci && npm run build +``` + + + +### O fuerza el uso literal + +Borra las anulaciones de compilación e inicio, y luego configura `dockerfilePath` en la misma actualización. Las anulaciones tienen prioridad sobre la ruta del archivo: + +```bash +lizard service set api --set buildCommand=null --set startCommand=null --set dockerfilePath=Dockerfile +``` + + + +## Ver también + +- [Proceso de compilación](/concepts/build-pipeline) — el orden completo de decisión de compilación. +- [Referencia de configuración de compilación](/concepts/build-pipeline#build-configuration-reference) +- [Implementar cualquier aplicación Python en Lizard](https://lizard.build/blog/python-app-hosting#deploying-any-python-app-on-lizard) — cuándo dejar que lizardpack escriba el Dockerfile y cuándo aportar el tuyo. + +Cambiar estos campos de compilación puede iniciar una compilación. Revisa `lizard events` antes de enviar otro `redeploy`, para evitar iniciar una segunda compilación. diff --git a/_locales/es/deploy/troubleshooting/service-never-healthy.mdx b/_locales/es/deploy/troubleshooting/service-never-healthy.mdx new file mode 100644 index 0000000..f1c460b --- /dev/null +++ b/_locales/es/deploy/troubleshooting/service-never-healthy.mdx @@ -0,0 +1,59 @@ +--- +description: "La compilación se completa, pero el despliegue sigue sin estar healthy. Vinculación de puertos, modo worker accidental y otras causas de una verificación de estado fallida." +--- + + + +# Mi servicio se despliega pero nunca pasa a healthy + +La compilación se completa, las réplicas se inician, pero el despliegue sigue pendiente, se marca como unhealthy o nunca recibe tráfico. + + + +## Qué significa esto + +La verificación de estado de la plataforma —que comprueba que se puede acceder al puerto de tu app— nunca se completa correctamente, así que el tráfico nunca se redirige a las nuevas réplicas. + + + +## Por qué puede pasar esto + +- **Tu app no está escuchando en el puerto esperado.** Lizard inyecta una variable de entorno `PORT` (puerto de contenedor predeterminado `3000`) y comprueba que se pueda acceder a tu app ahí. Si tu app tiene otro puerto fijado en el código, o nunca se enlaza a ninguno, la verificación de estado falla indefinidamente. Una app de Python es el caso más habitual: `gunicorn` y `uvicorn` se enlazan a `127.0.0.1` a menos que les indiques otra cosa, y la sonda viene desde fuera del proceso. [Hosting de apps Python](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) tiene la línea `--bind 0.0.0.0:$PORT` que necesita cada framework. +- **El servicio está accidentalmente en modo worker.** Configurar `containerPort=0` pone un servicio en [modo worker](/deploy/workers), lo que **omite por completo la verificación de estado y el registro en el balanceador de carga**. Un servicio que debería servir HTTP pero se cambió a `containerPort=0` se desplegará "correctamente" y simplemente nunca servirá nada: el modo worker oculta el problema subyacente de arranque en lugar de mostrarlo. + + + +## Posibles soluciones + + + +### Comprueba el puerto actual + +```bash +lizard port --service api +``` + +Si esto muestra `worker mode`, el servicio tiene `containerPort=0`. Vuelve a configurarlo con un puerto real si este servicio debe servir HTTP: + +```bash +lizard port 3000 --service api +lizard redeploy --service api +``` + + + +### Confirma que tu app está escuchando donde Lizard espera + +Revisa los logs de ejecución para detectar errores de arranque y verifica el puerto al que la app realmente se enlazó frente al que Lizard inyectó: + +```bash +lizard logs --service api +lizard ssh --service api -- env | grep PORT +``` + + + +## Ver también + +- [Background Workers](/deploy/workers) — cuándo `containerPort=0` es (y no es) la opción correcta. +- [Despliegues → lifecycle](/concepts/deployments#lifecycle) — dónde se sitúa la verificación de estado dentro de un despliegue. diff --git a/_locales/es/deploy/upload.mdx b/_locales/es/deploy/upload.mdx new file mode 100644 index 0000000..f65e6ba --- /dev/null +++ b/_locales/es/deploy/upload.mdx @@ -0,0 +1,84 @@ +--- +description: "Publica el directorio actual con lizard up, sin necesidad de Git. Cubre el manejo de gitignore, las anulaciones de compilación y arranque, y el uso sin interfaz en CI." +--- + + + +# Desplegar desde código local + +Cuando tu código no está en GitHub — o simplemente quieres iterar rápido — sube el directorio actual directamente con `lizard up`. Empaqueta tu árbol de trabajo como un tarball, lo envía a los nodos de compilación y lo despliega. + + + +## Desplegar el directorio actual + +```bash +lizard up +``` + +- Sube el directorio actual como un tarball, respetando `.gitignore` (desactívalo con `--no-gitignore`). +- Fuerza `sourceType=upload`. +- Transmite los logs de compilación por SSE y muestra la URL en vivo al finalizar. + +Si el directorio todavía no está vinculado a un proyecto, `up` ejecuta primero `init`. En un TTY eso es interactivo; en un entorno no TTY (CI) **no** creará un proyecto silenciosamente: devuelve un error y te pide que ejecutes `lizard init --name ` (o que pases `--name`). Esto evita que un error tipográfico genere un proyecto vacío. + + + +## Banderas comunes + +| Bandera | Propósito | +|------|---------| +| `-s, --service ` | Apuntar a un servicio específico o crearlo | +| `--build-command ` | Anular el comando de compilación | +| `--start-command ` | Anular el comando de arranque | +| `--pre-deploy-command ` | Ejecutar una vez antes de cada despliegue (p. ej., migraciones) | +| `--port ` | Puerto del contenedor (`0` = [modo worker](/deploy/workers)) | +| `--region ` | Región donde desplegar | +| `-d, --detach` | Iniciar el despliegue y salir sin transmitir logs | +| `-c, --ci` | Salida amigable para CI | +| `--no-gitignore` | Subir todo, ignorando `.gitignore` | + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +## Configurar comandos de compilación/arranque + +Pasar `--build-command` o `--start-command` cambia el servicio a la ruta de **Dockerfile sintetizado**. En esa ruta, `Procfile` y `package.json` `scripts.start` **no** se leen — establece el comando de arranque explícitamente (o incluye un `CMD` en tu propio Dockerfile). Consulta [Proceso de compilación](/concepts/build-pipeline). Python es donde esto más suele afectar: [Django, Flask and FastAPI](https://lizard.build/blog/python-app-hosting#deploying-django) necesitan cada uno una línea distinta de `gunicorn` o `uvicorn`. + + + +## Volver a desplegar un servicio subido + +`lizard up` vuelve a subir y recompilar. Para recompilar la **última** subida con las variables actuales sin volver a subir: + +```bash +lizard redeploy --service api +``` + + + +## Sin interfaz / CI + +Para flujos no interactivos, vincula el proyecto explícitamente antes de desplegar: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +## Cuándo conviene usar GitHub en su lugar + +La subida es excelente para iterar rápido y para situaciones sin remoto. Para cualquier cosa de larga duración, conviene preferir una [fuente de GitHub](/deploy/github) para que los pushes vuelvan a desplegar automáticamente y tengas un historial de despliegues limpio. + + + +## Ver también + +- [`lizard up`](/cli/up) — la referencia completa del comando. +- [Proceso de compilación](/concepts/build-pipeline) — cómo se detecta y compila tu stack. diff --git a/_locales/es/deploy/workers.mdx b/_locales/es/deploy/workers.mdx new file mode 100644 index 0000000..448ee4e --- /dev/null +++ b/_locales/es/deploy/workers.mdx @@ -0,0 +1,124 @@ +--- +description: "Ejecuta consumidores de colas y bucles de sondeo sin puerto HTTP. Qué cambia con containerPort=0, cómo activar el modo worker y cuándo no usarlo." +--- + + + +# Workers en segundo plano + +No todos los servicios sirven HTTP. Los consumidores de colas, reconcilers, bucles de sondeo estilo cron y otras cargas de trabajo en segundo plano no escuchan en un puerto: ejecútalos en **modo worker** configurando el puerto del contenedor en `0`. + + + +## Qué cambia el modo worker + +Cuando `containerPort=0`, la plataforma: + +- **Omite la inyección de `PORT`** — el worker no se enlaza en ningún sitio. +- **Omite la comprobación de accesibilidad del puerto** — sin spam de logs de `app port X unreachable` ni estado "unhealthy" por falsos positivos. +- **Omite `EXPOSE`** en el Dockerfile sintetizado. +- **Omite el registro de rutas del balanceador de carga** — no se sirve nada. (Puede que siga apareciendo un dominio `*.onlizard.com` generado en el servicio, pero no responderá.) + + + +## Activar el modo worker + +Tres formas equivalentes: + +```bash +# New upload-source worker +lizard up --port 0 + +# Flip an existing service +lizard port 0 --service worker + +# Via the config:apply path +lizard service set worker --set containerPort=0 +``` + +El modo worker es un cambio tajante: hace falta un redespliegue para que el cambio de puerto surta efecto. + + + +## Comprobar el puerto actual + +```bash +lizard port --service worker +``` + +Imprime el puerto actual del contenedor, o `worker mode` cuando es `0`. + + + +## Cuándo *no* usar el modo worker + +No uses el modo worker para un servicio HTTP normal que simplemente tarda en arrancar. El modo worker desactiva por completo la comprobación de accesibilidad, así que **ocultará** errores de "el listener nunca llegó a levantarse". Si tu servicio debe servir tráfico, mantén un puerto real y corrige el arranque. + + + +## Ejecutar un consumidor de cola + +Usa el [ejemplo redis-worker](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/redis-worker). Mueve un trabajo de una lista pendiente a una lista de procesamiento, guarda su resultado en mayúsculas y confirma el trabajo en una transacción de Redis. Mantén una sola réplica: la recuperación al inicio asume un único consumidor. El ejemplo usa Python 3.13 y redis-py 6.4.0. + +Desde el directorio que contiene su Dockerfile: + +```bash +lizard init --name queue-example +lizard add --service worker +lizard add redis +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +lizard up --service worker --port 0 +``` + +Inicia sesión con `lizard login` si un comando indica que se requiere autenticación. Usa el nombre real de la base de datos si no es `redis`. Mantén la referencia entre comillas. Configúrala antes de subir la aplicación. En macOS con Lizard CLI 0.3.92, antepone `COPYFILE_DISABLE=1` a `lizard up` para excluir metadatos AppleDouble. + +Comprueba el evento final del despliegue y luego comprueba el worker: + +```bash +lizard port --service worker +lizard logs --service worker --json +lizard ssh --service worker -- python jobs.py enqueue first-job +lizard ssh --service worker -- python jobs.py result first-job +``` + +El proceso imprime `Queue worker ready`. Si el seguimiento de logs está vacío, continúa con la comprobación del trabajo más abajo; los [resultados de pruebas](/guides/validation) registran el límite de logs observado. El comando de resultado espera hasta 30 segundos e imprime `{"id": "first-job", "result": "HELLO"}`. Que el proceso esté en ejecución por sí solo no demuestra que pueda consumir un trabajo. Managed Redis se alcanza desde dentro del servicio; el comando de CLI no requiere que tu portátil alcance su dirección privada. + + + +## Verificar un reinicio + +Para este servicio de prueba, reinicia el worker y envía otro trabajo: + +```bash +lizard restart --service worker +lizard ssh --service worker -- python jobs.py result first-job +lizard ssh --service worker -- python jobs.py enqueue after-restart +lizard ssh --service worker -- python jobs.py result after-restart +``` + +Espera a que el servicio vuelva a `running` en `lizard ps --json` si SSH todavía no está disponible. Ambos resultados deben ser `HELLO`. El primer resultado vive en Redis, así que reiniciar un worker no lo elimina. Al arrancar, el consumidor único devuelve las entradas de procesamiento sin terminar a la lista pendiente. + +Esta demo solo acepta los trabajos JSON creados por `jobs.py`. No implementa una cola de mensajes fallidos, validación para productores no confiables ni efectos externos exactamente una vez. Usa una biblioteca de colas consolidada y handlers idempotentes para pagos, correo u otros efectos. La durabilidad y las copias de seguridad de Redis son independientes del comportamiento de reinicio del worker; consulta [almacenamiento y recuperación](/platform/storage-and-recovery). + + + +## Solución de problemas + +| Síntoma | Comprobar | +|---|---| +| Falta el servicio | Ejecuta `lizard add --service worker` después de crear el proyecto. | +| No aparece `Queue worker ready` | Comprueba `REDIS_URL` con alcance de servicio, la disponibilidad del addon y los errores de conexión. No imprimas nunca la cadena de conexión. | +| El worker espera un puerto HTTP | Configura `containerPort=0`; cambiarlo en un servicio en ejecución requiere un redespliegue. | +| No hay resultado después de 30 segundos | Lee los logs del worker y verifica el ID del trabajo. Este ejemplo solo acepta trabajos de su propio `jobs.py`. | +| Efectos duplicados | Un reintento puede ejecutar el trabajo otra vez. Este ejemplo guarda un resultado por ID de trabajo; los efectos externos requieren su propia idempotencia. | + + + +## Ver también + +- [`lizard port`](/cli/port) — muestra o cambia el puerto del contenedor de un servicio. +- [El servicio nunca llega a healthy](/deploy/troubleshooting/service-never-healthy) — la configuración incorrecta del modo worker más común. +- [Managed Addons](/addons) — Redis, Postgres y S3 para cargas de trabajo con estado. +- [Hosting de apps Python](https://lizard.build/blog/python-app-hosting#deploying-django) — un worker de Celery es la misma imagen con un comando distinto y sin puerto HTTP. + +Consulta los [resultados de pruebas del escenario](/guides/validation) para ver versiones comprobadas, resultados en la nube y limitaciones restantes. diff --git a/_locales/es/framework-guides/_meta.ts b/_locales/es/framework-guides/_meta.ts new file mode 100644 index 0000000..84c2051 --- /dev/null +++ b/_locales/es/framework-guides/_meta.ts @@ -0,0 +1,16 @@ +export default { + index: "Descripción general", + nextjs: { title: "Next.js", display: "children" }, + react: "React (Vite)", + vue: "Vue (Vite)", + astro: "Astro", + nuxt: "Nuxt", + sveltekit: "SvelteKit", + fastapi: "FastAPI", + django: "Django", + docusaurus: "Docusaurus", + vitepress: "VitePress", + hugo: "Hugo", + 'static-routing': "Rutas estáticas y 404", + validation: "Versiones probadas y resultados", +}; diff --git a/_locales/es/framework-guides/astro.mdx b/_locales/es/framework-guides/astro.mdx new file mode 100644 index 0000000..c6b44bd --- /dev/null +++ b/_locales/es/framework-guides/astro.mdx @@ -0,0 +1,98 @@ +--- +description: "Implementa Astro en Lizard como un sitio estático o con el adaptador standalone de Node. Configura la salida, los comandos de compilación, los puertos y las comprobaciones para rutas del servidor y páginas faltantes." +--- + + + +# Implementar Astro en Lizard + +Astro tiene dos rutas de implementación en Lizard: servir un directorio estático `dist/` en el puerto `80`, o ejecutar el adaptador standalone de Node en el puerto `3000` para rutas bajo demanda. Elige el modo antes de implementar porque el adaptador cambia tanto la salida como el entorno de ejecución. + + + +## Elige un modo + +| Modo | Configuración | Entorno de ejecución | Puerto | +|---|---|---|---| +| Sitio estático | Salida estática sin un adaptador de servidor | nginx sirve `dist/` | `80` | +| Servidor Node | `@astrojs/node` en modo standalone | `node ./dist/server/entry.mjs` | `3000` | + +Ambas rutas usan un script `build` que ejecuta `astro build`. Haz commit del lockfile y mantén la ruta de salida predeterminada `dist`. La detección lee la configuración de Astro y las dependencias instaladas. Una dependencia de adaptador Node sin usar, por sí sola, no selecciona la ruta del servidor. Usa valores literales de `output` y de configuración del adaptador; los valores dinámicos, las rutas de salida personalizadas y el modo middleware necesitan un Dockerfile. + + + +## Configura un servidor Node + +Para páginas bajo demanda, añade una versión del adaptador Node compatible con tu versión de Astro: + +```bash +npx astro add node +``` + +Comprueba `astro.config.mjs`: + +```js +import { defineConfig } from 'astro/config'; +import node from '@astrojs/node'; + +export default defineConfig({ + output: 'server', + adapter: node({ mode: 'standalone' }), +}); +``` + +El modo standalone inicia su propio servidor HTTP. El modo middleware requiere un servidor independiente y no encaja con este comando de inicio. Lee la [guía del adaptador Node de Astro](https://docs.astro.build/en/guides/integrations-guide/node/) si necesitas middleware o una mezcla de rutas prerenderizadas y bajo demanda. + + + +## Prueba localmente + +```bash +npm ci +npm run build +``` + +Para el modo Node: + +```bash +HOST=0.0.0.0 PORT=3000 node ./dist/server/entry.mjs +``` + +Solicita una ruta que realmente se ejecute en el servidor y un recurso compilado. Para un sitio estático, usa `npm run preview` localmente e inspecciona los archivos de ruta generados en `dist/`. + + + +## Implementa + +Después de la [configuración de CLI](/framework-guides#prepare-the-project), crea el proyecto: + +```bash +lizard init --name astro-app +lizard add --service web +``` + +Para el adaptador Node: + +```bash +lizard up --service web --port 3000 +``` + +Para un sitio estático: + +```bash +lizard up --service web --port 80 +``` + +Usa solo el comando para el modo que hayas elegido. Deja sin configurar las anulaciones del comando del servicio para la detección de lizardpack. Lee `lizard logs --build --service web --json` y luego revisa los logs del entorno de ejecución y la URL en vivo. + + + +## Variables, sesiones y rutas + +Los valores usados para generar HTML estático requieren una nueva compilación cuando cambian. El código del servidor puede leer variables de ejecución mediante los mecanismos compatibles con tu versión de Astro; configúralas en [variables y secretos](/variables). Los valores visibles en el navegador no deben contener credenciales. + +Si tu aplicación usa sesiones, elige un almacenamiento que se adapte a reinicios y múltiples réplicas. No dependas del sistema de archivos del contenedor como un almacén compartido y duradero. Consulta [almacenamiento y recuperación](/platform/storage-and-recovery). + +Para un sitio de contenido estático, prueba una URL inexistente y usa [rutas estáticas y 404](/framework-guides/static-routing) para devolver el estado correcto. Si una implementación SSR se detiene o no sirve rutas, verifica que `dist/server/entry.mjs` exista, que el adaptador use el modo standalone y que el puerto del servicio sea `3000`. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de implementación del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/django.mdx b/_locales/es/framework-guides/django.mdx new file mode 100644 index 0000000..13670a7 --- /dev/null +++ b/_locales/es/framework-guides/django.mdx @@ -0,0 +1,221 @@ +--- +description: "Despliega Django en Lizard con Gunicorn, un módulo WSGI explícito, el puerto 8000, configuración de producción, migraciones de base de datos y un plan para archivos estáticos y subidos." +--- + + + +# Desplegar Django en Lizard + +Ejecuta Django en Lizard con Gunicorn y el módulo WSGI de tu proyecto en el puerto `8000`. Prepara la configuración de producción, el acceso a la base de datos y la publicación de archivos estáticos antes de depender de la app desplegada. `manage.py runserver` es un servidor de desarrollo. + + + +## Establecer el comando de inicio + +Esta guía asume `manage.py`, `requirements.txt` y un paquete del proyecto llamado `config` que contiene `wsgi.py`. Reemplaza `config` por el nombre real de tu paquete. + +Incluye Django, Gunicorn y el controlador de base de datos que use tu app en tus requirements probados. Añade un `Procfile`: + +```text +web: gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +El módulo explícito evita ambigüedades cuando la configuración vive en paquetes anidados. Una app ASGI con WebSockets necesita un servidor ASGI y un comando de arranque distinto; esta guía cubre WSGI. + +| Ajuste | Valor | +|---|---| +| Instalación | `pip install -r requirements.txt` | +| Entorno de ejecución | Gunicorn con tu módulo WSGI | +| Puerto del servicio | `8000` | +| Directorio de trabajo | Directorio que contiene `manage.py` | + + + +## Preparar la configuración de producción + +Django espera un diccionario `DATABASES` en `settings.py`. Establecer `DATABASE_URL` solo en el servicio no conecta Django a PostgreSQL. Los pasos de abajo crean [Managed Postgres](/addons/postgres), pasan su URL a la app y convierten esa URL en la configuración de conexión de Django. + +Añade estos paquetes a `requirements.txt`, conservando cualquier otra dependencia que necesite tu app. Estas son las versiones usadas por el [ejemplo completo](https://github.com/lizard-build/docs/tree/main/_examples/django): + +```text +Django==6.1.1 +gunicorn==26.2.0 +whitenoise==6.12.0 +psycopg[binary]==3.3.5 +dj-database-url==3.1.2 +``` + +`psycopg` es el controlador de PostgreSQL. `dj-database-url` lee el nombre de la base de datos, usuario, contraseña, host y puerto desde la URL de conexión. Reemplaza la configuración correspondiente en `settings.py` de tu proyecto por este bloque; conserva tus apps, middleware, plantillas y demás configuraciones existentes: + +```python +import os +from pathlib import Path + +import dj_database_url +from django.core.exceptions import ImproperlyConfigured + +BASE_DIR = Path(__file__).resolve().parent.parent + + +def required_env(name): + value = os.environ.get(name, "").strip() + if not value: + raise ImproperlyConfigured(f"Set the {name} environment variable.") + return value + + +def env_list(name): + values = [item.strip() for item in required_env(name).split(",") if item.strip()] + if not values: + raise ImproperlyConfigured(f"Set at least one value in {name}.") + return values + + +SECRET_KEY = required_env("SECRET_KEY") +debug_value = os.environ.get("DEBUG", "false").strip().lower() +if debug_value not in {"true", "false"}: + raise ImproperlyConfigured("DEBUG must be true or false.") +DEBUG = debug_value == "true" +ALLOWED_HOSTS = env_list("ALLOWED_HOSTS") +CSRF_TRUSTED_ORIGINS = env_list("CSRF_TRUSTED_ORIGINS") +DATABASES = { + "default": dj_database_url.parse( + required_env("DATABASE_URL"), + conn_max_age=60, + conn_health_checks=True, + ) +} +``` + +No dejes una asignación anterior de `DATABASES`, `SECRET_KEY` o `DEBUG` más adelante en el archivo: reemplazaría estos valores. Este ejemplo requiere valores no vacíos para `SECRET_KEY`, `DATABASE_URL`, `ALLOWED_HOSTS` y `CSRF_TRUSTED_ORIGINS`. Los valores ausentes o vacíos detienen el arranque con el nombre de la variable. `DEBUG` usa `false` por defecto; establécelo en `false` en el servicio desplegado. + +`ALLOWED_HOSTS` acepta nombres de host separados por comas sin esquema ni ruta, como `app.example.com,www.example.com`. `CSRF_TRUSTED_ORIGINS` acepta orígenes separados por comas con esquema, como `https://app.example.com`. Incluye un puerto para los orígenes locales que usen uno. El ejemplo requiere una lista explícita de orígenes; Django por sí mismo permite una lista vacía para apps que no necesitan orígenes de confianza adicionales. Confía solo en los orígenes que deban enviar formularios a esta app. Estas configuraciones no sustituyen los tokens CSRF. + +La URL proviene de un [secret o reference](/variables) del servicio, no de un valor enviado al código fuente. No uses SQLite local del contenedor como base de datos persistente para una app desplegada. Consulta [uso de dj-database-url](https://pypi.org/project/dj-database-url/) para el análisis de URL y las opciones de conexión. + +Con tus variables de entorno locales configuradas y PostgreSQL accesible, ejecuta: + +```bash +python -m pip install -r requirements.txt +python manage.py check --deploy +gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +Revisa la [lista de verificación de despliegue](https://docs.djangoproject.com/en/6.1/howto/deployment/checklist/) de Django para ver las configuraciones relevantes para tu app. El ejemplo pequeño no configura todos los ajustes de seguridad de producción. Verifica el manejo de proxy y HTTPS con la URL pública real antes de habilitar cookies seguras, HSTS o redirecciones. Confía en los encabezados reenviados de HTTPS solo cuando el proxy los controle. + + + +## Planificar archivos estáticos y migraciones + +Gunicorn por sí solo no sirve los archivos estáticos de Django. Elige un middleware de archivos estáticos configurado en la app o un host estático aparte. Recoge los recursos en la ruta que sirva esa configuración. La ruta de Python basada en requirements de lizardpack no ejecuta automáticamente `collectstatic`; colócalo en una compilación completa de Dockerfile cuando la app necesite ese paso. + +Para WhiteNoise, mantén `django.contrib.staticfiles` en `INSTALLED_APPS` e inserta `whitenoise.middleware.WhiteNoiseMiddleware` inmediatamente después del `SecurityMiddleware` de Django. Añade o actualiza estas configuraciones: + +```python +STATIC_URL = "/static/" +STATIC_ROOT = BASE_DIR / "staticfiles" +STORAGES = { + "default": {"BACKEND": "django.core.files.storage.FileSystemStorage"}, + "staticfiles": { + "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage", + }, +} +``` + +Conserva tu backend existente de `STORAGES["default"]` si la app ya almacena las subidas en otro lugar. WhiteNoise sirve recursos estáticos recolectados, no subidas de usuarios. + +Usa este Dockerfile en la raíz del proyecto: + +```dockerfile +FROM python:3.13-slim +WORKDIR /app +COPY requirements.txt ./ +RUN pip install --no-cache-dir -r requirements.txt +COPY . . +RUN SECRET_KEY=build-only-placeholder \ + DATABASE_URL=postgresql://build:build@127.0.0.1:1/build \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + python manage.py collectstatic --noinput +EXPOSE 8000 +CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"] +``` + +Los valores de la línea `RUN` existen solo para `collectstatic`. La URL de base de datos es un marcador de posición que apunta a un puerto local sin usar; no hay ninguna base de datos ejecutándose allí. Cargar la configuración analiza la URL, pero la recolección de recursos no necesita una conexión a la base de datos. No consultes la base de datos desde importaciones de módulos ni desde `AppConfig.ready()`. El ejemplo también pasa `collectstatic` con la red del contenedor deshabilitada. + +Estas asignaciones no se convierten en variables de entorno de runtime. Establece un `SECRET_KEY` nuevo y la referencia real de la base de datos en el servicio antes del arranque. No pases secrets de producción a la compilación de Docker. + +Crea `.dockerignore` y excluye las mismas rutas de las [subidas de código fuente](/cli/up): + +```text +.env* +.venv/ +venv/ +.git/ +__pycache__/ +*.pyc +*.sqlite3 +staticfiles/ +``` + +Mantén las subidas de usuarios en almacenamiento persistente, como [Managed Object Storage](/addons/storage), en lugar del directorio estático del contenedor. Revisa [almacenamiento y recuperación](/platform/storage-and-recovery). + +Trata las migraciones de base de datos como un paso de despliegue aparte. Haz copias de seguridad de los datos cuando sea necesario, procura que las migraciones se puedan reintentar de forma segura y aplícalas antes de que las solicitudes requieran el nuevo esquema. Un comando previo al despliegue no sustituye la comprobación del comportamiento ante concurrencia y fallos. + + + +## Desplegar y verificar + +Después de la [configuración de CLI](/framework-guides#prepare-the-project), conecta un [servicio de GitHub](/deploy/github), configura sus secrets y ajustes de producción, y despliega con el puerto de contenedor `8000`. Para un proyecto nuevo basado en subidas: + +```bash +lizard init --name django-app +lizard add --service web +``` + +Crea [Managed Postgres](/addons/postgres) en este proyecto. Si ya tienes una instancia, omite `add postgres` y usa su nombre en la referencia: + +```bash +lizard add postgres --name postgres +``` + +Establece los [secrets del servicio](/cli/secrets) de la app. El `postgres` en `${{postgres.DATABASE_URL}}` nombra el servicio de base de datos, no un alias de base de datos de Django. Lizard resuelve la [reference](/variables/references) en el momento del despliegue e inyecta la URL resultante en el proceso `web`. Las comillas simples evitan que tu shell expanda la reference. El bloque `settings.py` de arriba convierte luego la URL en `DATABASES["default"]`. + +```bash +DJANGO_SECRET_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(48))')" +lizard secrets set SECRET_KEY="$DJANGO_SECRET_KEY" \ + DATABASE_URL='${{postgres.DATABASE_URL}}' DEBUG=false \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + --service web +lizard up --service web --port 8000 +lizard ps --json +``` + +`localhost` es una configuración de host temporal que permite que el proceso arranque mientras obtienes su nombre de host público; las solicitudes públicas devolverán 400. Si ya conoces el nombre de host, establécelo antes de la primera subida. En caso contrario, reemplaza estos marcadores de posición por el nombre de host y el origen HTTPS devueltos para tu servicio: + +```bash +lizard secrets set ALLOWED_HOSTS=YOUR_PUBLIC_HOST \ + CSRF_TRUSTED_ORIGINS=https://YOUR_PUBLIC_HOST --service web +``` + +Un destino o clave de reference ausente puede resolverse como una cadena vacía. La comprobación de valor obligatorio entonces detiene Django con `Set the DATABASE_URL environment variable.`. Comprueba el nombre del servicio de base de datos y su clave `DATABASE_URL`; no imprimas la URL de conexión en los logs. + +El cambio de variable reinicia el proceso. Excluye los entornos virtuales locales, secrets y bases de datos locales de las subidas. Una vez que el proceso esté en ejecución, aplica las migraciones: + +```bash +lizard ssh --service web -- python manage.py migrate --noinput +``` + +Ejecuta el comando de nuevo para comprobar que no quedan migraciones. No trates una comprobación correcta del puerto como prueba de que las tablas existen. + +Comprueba la URL de la app, una página respaldada por base de datos, el envío de un formulario y un recurso estático. Si la app usa el admin de Django, comprueba también su CSS. Lee `lizard logs --service web --json` para ver errores de importación o de configuración. Una respuesta 400 suele significar que `ALLOWED_HOSTS` es incorrecto; la falta de CSS normalmente significa que los recursos estáticos no se recolectaron o no se sirvieron. Comprueba el error real antes de cambiar configuraciones. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. + + + + +## Reproducir este ejemplo + +El [ejemplo de Django](https://github.com/lizard-build/docs/tree/main/_examples/django) incluye la configuración, Dockerfile, requirements, un formulario respaldado por base de datos y un ejecutor de pruebas. Cópialo en un directorio independiente y ejecuta `python3 tests/verify.py` con Docker en ejecución. Compila la imagen, inicia PostgreSQL local, comprueba migraciones y el comportamiento HTTP, y detiene sus contenedores de prueba. No crea servicios en Lizard. Consulta su README para ver las comprobaciones y los recursos de Docker conservados. + +La comprobación del 14 de septiembre de 2026 cubre este ejemplo revisado en contenedores locales de Linux. Los resultados anteriores en la nube enlazados arriba cubren la guía del 9 de septiembre; la configuración revisada aún no ha tenido un nuevo despliegue en la nube. diff --git a/_locales/es/framework-guides/docusaurus.mdx b/_locales/es/framework-guides/docusaurus.mdx new file mode 100644 index 0000000..c5667ad --- /dev/null +++ b/_locales/es/framework-guides/docusaurus.mdx @@ -0,0 +1,88 @@ +--- +description: "Despliega Docusaurus en Lizard como un sitio de documentación estático. Compila el directorio build, configura URL y baseUrl, usa el puerto 80 y verifica rutas directas y 404 reales." +--- + + + +# Desplegar Docusaurus en Lizard + +Compila Docusaurus en Lizard y sirve su directorio generado `build/` mediante nginx en el puerto `80`. El despliegue de producción sirve archivos estáticos; no ejecuta el servidor de desarrollo `docusaurus start`. + +Empieza con el [ejemplo de código fuente completo](https://github.com/lizard-build/docs/tree/main/_examples/docusaurus), que incluye la configuración y los archivos usados por esta guía. + + + +## Preparar el sitio + +Ejecuta desde el directorio de Docusaurus que contiene `package.json`, su lockfile y `docusaurus.config.*`. Mantén `@docusaurus/core` en las dependencias y un script de compilación que ejecute `docusaurus build`. + +| Ajuste | Valor | +|---|---| +| Compilación | `npm run build` | +| Salida | `build/` | +| Entorno de ejecución | nginx | +| Puerto del servicio | `80` | + +Configura `url` en la configuración de Docusaurus con el origen público previsto del sitio y `baseUrl` con la ruta donde se ejecutará. Para un sitio en la raíz del dominio, `baseUrl` es `/`. Cuando ya conozcas el nombre de host final, vuelve a compilar con ese nombre de host para que las URL canónicas generadas y las entradas del sitemap lo usen. + +Elige una política coherente para la barra final y revisa los archivos resultantes. Mantén el directorio de salida predeterminado a menos que proporciones un Dockerfile que copie tu directorio personalizado. La [guía de despliegue de Docusaurus](https://docusaurus.io/docs/deployment) explica estas opciones del framework. + + + +## Compilar y comprobar localmente + +```bash +npm ci +npm run build +npm run serve +``` + +El último comando supone que tu proyecto tiene el script `serve` del scaffold. Comprueba la página de inicio, una página de documentación anidada, una imagen y una página versionada si usas versiones de docs. Corrige los enlaces rotos que informe la compilación antes del despliegue. + + + +## Desplegar + +Después de la [configuración de CLI](/framework-guides#prepare-the-project): + +```bash +lizard init --name docusaurus-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Si usas el nombre de host generado, léelo después del primer despliegue: + +```bash +lizard service show web --json +``` + +Configura `url` en `docusaurus.config.js` con ese nombre de host: + +```js +url: 'https://YOUR_PUBLIC_HOST', +``` + +Sube la configuración modificada para que la compilación use la URL pública: + +```bash +lizard up --service web --port 80 +``` + + +Confirma el código fuente, los plugins, la configuración y el lockfile. Excluye los archivos `node_modules/`, `build/`, `.docusaurus/` y `.env` de las subidas. Deja sin configurar las anulaciones del comando del servicio para usar la ruta de detección de Docusaurus. + + + +## Servir rutas internas y páginas inexistentes + +Las compilaciones nuevas de Docusaurus sirven los archivos de rutas generados y devuelven HTTP 404 para rutas desconocidas. No se necesita un Dockerfile personalizado para esta política de enrutamiento. Si tu servicio todavía usa una imagen compilada antes de la corrección de enrutamiento de septiembre de 2026, recompílala. Usa [rutas estáticas y 404](/framework-guides/static-routing) solo cuando necesites un comportamiento personalizado de nginx. + +Después del despliegue, solicita directamente una URL anidada de docs, actualízala y comprueba el estado de una URL inventada. Inspecciona también la URL canónica y el sitemap en el nombre de host final. Una página de error visible con HTTP 200 sigue siendo un soft 404. + +Si faltan recursos, compara sus URL con `baseUrl`. Si una ruta interna devuelve la página de inicio, inspecciona la estructura de archivos generada y las reglas de nginx. Si el contenido anterior permanece después de editar un valor de entorno o un archivo Markdown, verifica que realmente se haya completado una nueva compilación; el HTML estático solo cambia con una compilación. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. + diff --git a/_locales/es/framework-guides/fastapi.mdx b/_locales/es/framework-guides/fastapi.mdx new file mode 100644 index 0000000..40a3c0b --- /dev/null +++ b/_locales/es/framework-guides/fastapi.mdx @@ -0,0 +1,98 @@ +--- +description: "Despliega FastAPI en Lizard con Uvicorn, requirements.txt, un Procfile y el puerto 8000. Verifica un endpoint de estado y diagnostica errores de importación, host y dependencias." +--- + + + +# Desplegar FastAPI en Lizard + +Ejecuta FastAPI en Lizard con Uvicorn escuchando en `0.0.0.0:8000`. Incluye tanto FastAPI como Uvicorn en las dependencias de la app. Importar un archivo que declara `app = FastAPI()` no inicia por sí solo un servidor HTTP. + + + +## Proyecto de ejemplo + +El [ejemplo de FastAPI](https://github.com/lizard-build/fastapi-example) incluye una app, un Procfile, dependencias fijadas, una licencia MIT y pruebas HTTP. Su CI ejecuta el punto de entrada de Uvicorn en producción sobre Linux. También desplegamos el commit `df522c1` desde GitHub y comprobamos estado, OpenAPI, documentación interactiva, eco JSON, entrada no válida y una ruta inexistente mediante HTTPS público el 2026-09-09. + + + +## Preparar una app + +Este ejemplo usa `requirements.txt` y un `main.py` en la raíz de la aplicación: + +```python +from fastapi import FastAPI + +app = FastAPI() + +@app.get("/health") +def health(): + return {"status": "ok"} +``` + +Añade `fastapi` y `uvicorn` a tu flujo de dependencias y guarda las versiones resueltas y probadas en `requirements.txt`. Selecciona tu versión menor de Python en `.python-version`, por ejemplo `3.13`, si tus dependencias la admiten. + +Crea un `Procfile` con un destino de importación explícito: + +```text +web: uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +`main:app` significa el objeto `app` en `main.py`. Para `src/api.py`, usa la ruta de importación que funcione desde la raíz de tu app, como `src.api:app`. El Procfile explícito evita depender de la detección de patrones de código fuente en estructuras personalizadas. + +| Ajuste | Valor | +|---|---| +| Install | `pip install -r requirements.txt` | +| Start | Comando `web:` del Procfile | +| Puerto del servicio | `8000` | +| Compilar output | Código fuente de Python y dependencias instaladas | + + + +## Probar localmente + +Usa un entorno virtual local: + +```bash +python -m venv .venv +source .venv/bin/activate +pip install -r requirements.txt +uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +En otra terminal: + +```bash +curl --fail http://localhost:8000/health +``` + +Deberías obtener una respuesta correcta que contenga `{"status":"ok"}`. Mantén el modo reload para desarrollo. La [guía del servidor FastAPI](https://fastapi.tiangolo.com/deployment/manually/) explica el servidor ASGI y el destino de importación. + + + +## Desplegar + +Después de la [configuración de CLI](/framework-guides#prepare-the-project), sube desde la raíz de la aplicación: + +```bash +lizard init --name fastapi-app +lizard add --service api +lizard up --service api --port 8000 +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +Excluye los archivos `.venv/`, `__pycache__/` y `.env`. Deja sin configurar las anulaciones de build/start del servicio para que lizardpack lea el Procfile. La ruta basada en requirements aquí no necesita un comando de compilación separado. + +Solicita `/health` en la URL HTTPS devuelta y luego prueba una acción real de la API. Una sonda de estado TCP solo confirma que el proceso abre su puerto; tu endpoint de estado puede añadir comprobaciones importantes para la app. + + + +## Datos y fallos comunes + +Configura las credenciales mediante [variables y secretos](/variables). Añade [Managed Postgres](/addons/postgres) cuando la app necesite una base de datos, y usa una referencia de conexión con alcance del servicio. Los archivos locales del contenedor no son almacenamiento persistente para la aplicación; consulta [almacenamiento y recuperación](/platform/storage-and-recovery). + +Para `No module named uvicorn`, revisa los requirements instalados. Para un error de importación ASGI, ejecuta localmente el comando exacto del Procfile desde la misma raíz. Si un servicio nunca llega a estar saludable, revisa el puerto `8000` y el host de enlace. Si el proceso se cierra sin registros del servidor, confirma que ejecuta Uvicorn en lugar de solo `python main.py`. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/hugo.mdx b/_locales/es/framework-guides/hugo.mdx new file mode 100644 index 0000000..ebdf8df --- /dev/null +++ b/_locales/es/framework-guides/hugo.mdx @@ -0,0 +1,89 @@ +--- +description: "Implementa Hugo en Lizard compilando public con hugo --minify y sirviéndolo en el puerto 80. Revisa la detección, los temas, baseURL, las rutas generadas y el estado de las páginas faltantes." +--- + + + +# Implementar Hugo en Lizard + +Lizard puede compilar un sitio fuente de Hugo con `hugo --minify` y servir `public/` mediante nginx en el puerto `80`. Empieza desde el directorio fuente de Hugo, con una configuración de Hugo y `content/`, en lugar de subir solo el HTML generado. + +Empieza con el [ejemplo fuente completo](https://github.com/lizard-build/docs/tree/main/_examples/hugo), que incluye la configuración y los archivos usados por esta receta. + + + +## Preparar el código fuente + +Incluye tu configuración de Hugo, contenido, layouts, assets y todos los archivos del tema necesarios para la compilación. El detector de Hugo busca configuración como `hugo.toml`, `hugo.yaml` o `config/_default/`, además de un directorio `content/`. + +| Ajuste | Valor | +|---|---| +| Compilación | `hugo --minify` | +| Salida | `public/` | +| Servidor de producción | nginx | +| Puerto del servicio | `80` | + +Configura `baseURL` con la URL pública prevista del sitio, incluida la barra final. Vuelve a compilar después de asignar un hostname diferente para que los enlaces y las entradas generadas del sitemap lo usen. Consulta la [guía de compilación y salida de Hugo](https://gohugo.io/getting-started/usage/). + + + +## Revisar las dependencias de compilación + +La imagen de compilación predeterminada de Hugo es `hugomods/hugo:base`; no fija una versión de Hugo para tu proyecto. Si un tema necesita una versión específica de Hugo, la edición extendida o herramientas de Node, usa un Dockerfile completo con esas dependencias y la versión que probaste. + +Una configuración de Hugo y `content/` seleccionan el compilador de Hugo antes de la detección de Go o Node. Los proyectos de Hugo Modules con `go.mod` usan una imagen de compilación con soporte para Go. Un archivo `package.json` hace que la compilación se detenga con una solicitud de Dockerfile: instala las dependencias de Node, compila los assets y luego ejecuta `hugo --minify`. Consulta el [orden de decisión de compilación](/concepts/build-pipeline#build-decision-order). + + + +## Compilar localmente e implementar + +```bash +hugo --minify +hugo server +``` + +Inspecciona `public/` después del primer comando. Usa el servidor local para revisar el contenido y el renderizado del tema; `hugo server` no es el comando de inicio de producción. + +Después de la [configuración de la CLI](/framework-guides#prepare-the-project), implementa el directorio fuente: + +```bash +lizard init --name hugo-site +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Si usas el hostname generado, léelo después de la primera implementación: + +```bash +lizard service show web --json +``` + +Configura `baseURL` en `hugo.toml` con ese hostname: + +```toml +baseURL = "https://YOUR_PUBLIC_HOST/" +``` + +Sube la configuración modificada para que la compilación use la URL pública: + +```bash +lizard up --service web --port 80 +``` + + +Excluye la salida generada localmente y los secretos. Para una subida, asegúrate de que los archivos fuente del tema realmente existan en el directorio que envías; una referencia remota a submodule por sí sola no es el contenido del tema. + + + +## Verificar el sitio implementado + +Abre la página principal en vivo, un artículo interno y una imagen. Revisa las URL canónicas generadas y `sitemap.xml`. Prueba el estado HTTP de una ruta inventada. Las compilaciones nuevas de Hugo sirven el HTML generado y devuelven HTTP 404 para las páginas faltantes. No se necesita un Dockerfile personalizado para el diseño simple de código fuente de esta guía. Vuelve a compilar imágenes antiguas para adoptar las reglas de enrutamiento actuales. + +Usa [rutas estáticas y 404](/framework-guides/static-routing) si necesitas una política personalizada de nginx. Una etapa de compilación personalizada de Hugo debe incluir la versión de Hugo y las herramientas que requiere el tema, ejecutar `hugo --minify` y copiar `public/` en la imagen de servicio. + +Si faltan assets del tema, inspecciona los logs de compilación, el código fuente del tema y `baseURL`. Si se inicia el compilador incorrecto, revisa que la configuración de Hugo y `content/` estén en la raíz de la subida e inspecciona las anulaciones existentes del servicio. Hugo produce archivos estáticos, así que los cambios de contenido requieren una nueva compilación. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de implementación del 9 de septiembre de 2026 y sus límites. + diff --git a/_locales/es/framework-guides/index.mdx b/_locales/es/framework-guides/index.mdx new file mode 100644 index 0000000..6cc09e9 --- /dev/null +++ b/_locales/es/framework-guides/index.mdx @@ -0,0 +1,69 @@ +--- +description: "Implementa Next.js, React, Vue, Astro, Nuxt, SvelteKit, FastAPI, Django, Docusaurus, VitePress y Hugo en Lizard. Encuentra comandos de compilación, adaptadores, puertos y comprobaciones." +--- + + + +# Guías de frameworks + +Implementa una aplicación de framework en Lizard desde el código fuente. Elige abajo tu framework y modo de renderizado, prepara su compilación de producción y luego impleméntalo con Lizard CLI o conecta un repositorio de GitHub. Las aplicaciones de servidor ejecutan un proceso; los sitios estáticos sirven los archivos generados mediante nginx. + + + +## Elige tu framework + +Estos ajustes describen las estructuras de proyecto estándar en las guías enlazadas. Los comandos asumen npm para proyectos de JavaScript. Las rutas de salida personalizadas, los adaptadores y las anulaciones de compilación pueden cambiar el resultado. + +| Framework | Compilación | Entorno de ejecución o salida | Puerto del servicio | +|---|---|---|---| +| [Next.js](/framework-guides/nextjs) | `npm run build` | `next start` mediante el script de inicio | `3000` | +| [Exportación estática de Next.js](/framework-guides/nextjs/static-export) | `npm run build` | `out/` mediante un Dockerfile | `80` | +| [React con Vite](/framework-guides/react) | `npm run build` | `dist/` | `80` | +| [Vue con Vite](/framework-guides/vue) | `npm run build` | `dist/` | `80` | +| [Astro](/framework-guides/astro) | `npm run build` | `dist/`, o el adaptador Node standalone | `80` estático; `3000` servidor | +| [Nuxt](/framework-guides/nuxt) | `npm run build` | `node .output/server/index.mjs` | `3000` | +| [SvelteKit](/framework-guides/sveltekit) | `npm run build` | `node build` con adapter-node | `3000` | +| [FastAPI](/framework-guides/fastapi) | Instala las dependencias de Python | `uvicorn main:app --host 0.0.0.0 --port 8000` | `8000` | +| [Django](/framework-guides/django) | Instala las dependencias de Python | Gunicorn con tu módulo WSGI | `8000` | +| [Docusaurus](/framework-guides/docusaurus) | `npm run build` | `build/` | `80` | +| [VitePress](/framework-guides/vitepress) | `npm run docs:build` | `docs/.vitepress/dist/` en esta guía | `80` | +| [Hugo](/framework-guides/hugo) | `hugo --minify` | `public/` | `80` | + + + +## Prepara el proyecto + +Ejecuta los comandos desde el directorio de la aplicación. Haz commit de los archivos fuente, la configuración y el archivo de bloqueo del paquete. Excluye `.env`, las dependencias locales y la salida de compilación local de las cargas. Los proyectos Node pueden seleccionar la versión major de Node en `.nvmrc`; el valor predeterminado actual es `22`. Esto selecciona una versión major, no una versión exacta de parche. + +Instala Lizard CLI e inicia sesión una vez: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +Cada guía usa un proyecto nuevo y un servicio llamado `web` o `api`. Crea ese servicio con `lizard add --service web` (o `api`) antes de la primera llamada a `lizard up --service`. `up --service` selecciona un servicio existente; no crea un servicio con nombre si falta. Para un proyecto existente, comprueba `lizard status --json` y `lizard ps --json` antes de implementar. El puerto debe coincidir con el proceso dentro del contenedor, que debe escuchar en `0.0.0.0`. + +Lizard CLI 0.3.95 excluye los metadatos de archivo de macOS durante las cargas. No se necesita ninguna configuración `COPYFILE_DISABLE`. Actualiza las versiones anteriores de CLI antes de seguir estas guías. + + + +## Elige GitHub o código fuente local + +Los comandos de la guía usan `lizard up` para cargar la carpeta actual. Ese comando cambia un servicio existente para cargar código fuente. Para mantener git push to deploy, [conecta GitHub](/deploy/github) en su lugar y usa en el repositorio los ajustes de compilación de la guía. Configura el puerto del servicio según la tabla. + + + +## Mantén consistentes los ajustes de compilación + +Estas guías usan la detección de lizardpack salvo cuando requieren un Dockerfile. Las anulaciones existentes de `buildCommand` o `startCommand` tienen prioridad sobre la detección y sobre el Dockerfile del repositorio. Consulta el [orden de decisión de compilación](/concepts/build-pipeline#build-decision-order) antes de cambiar de método de compilación. Configura scripts en `package.json` cuando una guía te lo indique; añadir una anulación de CLI es una ruta de compilación diferente. + + + +## Comprueba una versión + +Lee los registros de compilación, los registros de ejecución y la URL activa. Prueba una ruta interna, una ruta inexistente y cualquier acción de API o formulario. Un proceso que abre su puerto aún puede servir una página rota. Para los sitios generados, usa [rutas estáticas y 404](/framework-guides/static-routing) para evitar devolver la página de inicio con HTTP 200 para cada URL desconocida. + +La compatibilidad del entorno de ejecución no implica cachés compartidas, archivos locales persistentes ni todas las versiones de cada framework. Consulta [límites](/platform/limits), [almacenamiento y recuperación](/platform/storage-and-recovery) y [problemas conocidos](/platform/known-issues) cuando tu aplicación dependa de esas funciones. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de implementación del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/nextjs/_meta.ts b/_locales/es/framework-guides/nextjs/_meta.ts new file mode 100644 index 0000000..f5873a0 --- /dev/null +++ b/_locales/es/framework-guides/nextjs/_meta.ts @@ -0,0 +1,4 @@ +export default { + index: "Next.js", + 'static-export': { title: "Exportación estática", display: "oculto" }, +}; diff --git a/_locales/es/framework-guides/nextjs/index.mdx b/_locales/es/framework-guides/nextjs/index.mdx new file mode 100644 index 0000000..c158256 --- /dev/null +++ b/_locales/es/framework-guides/nextjs/index.mdx @@ -0,0 +1,95 @@ +--- +description: "Implementa Next.js en Lizard como un servidor Node.js. Configura next build, next start, el puerto 3000, variables de entorno y comprobaciones para páginas, APIs y Server Actions." +--- + + + +# Implementar Next.js en Lizard + +Ejecuta Next.js en Lizard como un servidor Node.js con `next build` y `next start`. Esta opción mantiene un servidor disponible para el renderizado en tiempo de solicitud, Route Handlers y Server Actions. Si todas las rutas se pueden compilar por adelantado, sigue [Exportación estática de Next.js](/framework-guides/nextjs/static-export) en su lugar. + + + +## Configuración de compilación + +| Ajuste | Valor | +|---|---| +| Raíz del proyecto | Directorio que contiene `package.json` y la configuración de Next.js | +| Script de compilación | `next build` | +| Script de inicio | `next start --hostname 0.0.0.0 --port 3000` | +| Salida de compilación | `.next/` | +| Puerto del servicio | `3000` | +| Entorno de ejecución | Node.js | + + + +## Prepara la app + +Mantén `next`, `react` y `react-dom` en tus dependencias y confirma tu lockfile. Integra estos scripts en `package.json`: + +```json +{ + "scripts": { + "dev": "next dev", + "build": "next build", + "start": "next start --hostname 0.0.0.0 --port 3000" + } +} +``` + +Usa la salida estándar de Next.js para esta guía. `output: 'export'` necesita un servidor estático, y `output: 'standalone'` necesita su propio inicio `server.js` y diseño de recursos. Ninguno usa esta receta de `next start` sin cambios. + +Selecciona una versión major de Node compatible en `.nvmrc`, como `22`. Excluye `.next/`, `node_modules/` y `.env*` del código fuente subido; mantén un archivo de entorno de ejemplo sin secretos si hace falta. + + + +## Prueba la compilación de producción localmente + +```bash +npm ci +npm run build +npm run start +``` + +En otra terminal, abre `http://localhost:3000` y prueba una ruta interna. Si la app tiene una API o una Server Acción, pruébala también. Superar solo la comprobación del servidor de desarrollo no demuestra que la compilación de producción funcione. + + + +## Implementar + +Después de [instalar Lizard CLI e iniciar sesión](/framework-guides#prepare-the-project), ejecuta desde el directorio de la app: + +```bash +lizard init --name nextjs-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Lizard detecta la dependencia `next` y ejecuta los scripts de compilación e inicio. Estos comandos asumen que el servicio no tiene reemplazos existentes para compilación o inicio. Usa la URL en la salida de implementación para repetir las comprobaciones locales. + + + +## Variables de entorno y datos + +Los valores de `NEXT_PUBLIC_*` pasan a formar parte del paquete del navegador durante la compilación. Mantén las credenciales en variables solo del servidor y configúralas para el servicio mediante [variables y secretos](/variables). El código que obtiene datos durante la compilación también necesita acceso a esos datos en el momento de compilar. Un reinicio en tiempo de ejecución no cambia el HTML o JavaScript ya generados. + +Los archivos de caché locales y los archivos subidos no forman un almacenamiento compartido entre réplicas. Revisa los requisitos de caché y de Server Acción de Next.js antes de escalar más allá de una réplica. Coloca los datos persistentes de la app en una base de datos o en almacenamiento de objetos, y consulta [almacenamiento y recuperación](/platform/storage-and-recovery). + + + +## Solución de problemas + +| Síntoma | Comprobar | +|---|---| +| `Missing script: start` | Agrega el script de inicio de producción anterior; `next dev` es para desarrollo local. | +| La app nunca pasa a estado healthy | Haz coincidir `--port 3000` con el comando de inicio y enlaza a `0.0.0.0`. | +| La URL pública de la API sigue teniendo su valor anterior | Vuelve a compilar con el nuevo valor de `NEXT_PUBLIC_*`. | +| La compilación no puede alcanzar una base de datos | Comprueba si una ruta obtiene datos en tiempo de compilación y si esa dependencia es accesible en ese momento. | +| La exportación estática falla con `next start` | Sigue la guía separada de exportación estática. | + +La [guía de self-hosting de Next.js](https://nextjs.org/docs/app/guides/self-hosting) cubre el comportamiento del caché, las imágenes y múltiples instancias a nivel del framework. Para errores de implementación, consulta [servicio nunca saludable](/deploy/troubleshooting/service-never-healthy). + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de implementación del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/nextjs/static-export.mdx b/_locales/es/framework-guides/nextjs/static-export.mdx new file mode 100644 index 0000000..23305e0 --- /dev/null +++ b/_locales/es/framework-guides/nextjs/static-export.mdx @@ -0,0 +1,106 @@ +--- +description: "Implementa una exportación estática de Next.js en Lizard con output export, un Dockerfile de nginx, puerto 80 y respuestas 404 reales. Descubre qué funciones todavía necesitan un servidor Node.js." +--- + + + +# Implementar una exportación estática de Next.js + +Una exportación estática de Next.js genera HTML, JavaScript y recursos en `out/`. Implementa ese directorio en Lizard con un Dockerfile de nginx. Usa esta ruta para páginas que pueden compilarse con antelación; usa la [guía del servidor Node.js](/framework-guides/nextjs) para funciones del servidor en tiempo de solicitud. + + + +## Configura la exportación + +Integra estas opciones en `next.config.mjs`: + +```js +/** @type {import('next').NextConfig} */ +const nextConfig = { + output: 'export', + trailingSlash: true, + images: { unoptimized: true }, +}; + +export default nextConfig; +``` + +Mantén `"build": "next build"` en `package.json`. Este ejemplo usa imágenes exportadas simples; un cargador de imágenes externo es otra opción. Genera todos los parámetros de rutas dinámicas necesarios durante la compilación. Las cookies en tiempo de solicitud, Server Actions y otras funciones que necesitan un servidor Next.js en ejecución no pueden ejecutarse en este contenedor estático. Revisa la [referencia de exportación estática de Next.js](https://nextjs.org/docs/app/guides/static-exports) comparándola con las funciones que usa tu app. + + + +## Añade un Dockerfile completo + +La ruta de detección automática de Next.js espera un servidor Node. No cambia a nginx solo porque la configuración exporte `out/`. Añade este Dockerfile en la raíz de la app; asume npm y un `package-lock.json` confirmado en el repositorio: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +RUN npm run build + +FROM nginx:alpine +COPY --from=build /app/out /usr/share/nginx/html +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +Crea `nginx.conf` junto a él: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + location / { + try_files $uri $uri/ =404; + } + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +La exportación con barra final crea directorios de ruta con `index.html`. La regla de nginx sirve esos directorios y devuelve HTTP 404 para rutas inexistentes. Añade `node_modules`, `.next`, `out`, `.git` y `.env*` a `.dockerignore` y excluye los archivos de compilación locales de las cargas. + + + +## Compila e implementa + +```bash +npm ci +npm run build +``` + +Comprueba que existan `out/index.html` y una ruta interna esperada. Con Docker disponible, prueba el servidor real localmente: + +```bash +docker build -t nextjs-static . +docker run --rm -p 8080:80 nextjs-static +``` + +Después de la [configuración de la CLI](/framework-guides#prepare-the-project), implementa en un nuevo servicio: + +```bash +lizard init --name nextjs-static +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +El Dockerfile completo incluye un paso de compilación con npm que lizardpack puede reconocer. En un servicio existente, inspecciona y borra las anulaciones de compilación/inicio en conflicto antes de seleccionar un Dockerfile; consulta el [orden de decisión de compilación](/concepts/build-pipeline#build-decision-order). + + + +## Verifica rutas y actualizaciones + +Solicita la página de inicio activa, una ruta interna exportada, un recurso JavaScript y una ruta inventada. La ruta inventada debe devolver HTTP 404, no la página de inicio con HTTP 200. Usa las comprobaciones de [rutas estáticas y 404](/framework-guides/static-routing#verify-http-responses). + +Todos los cambios del contenido exportado requieren una nueva compilación. Las variables de entorno en tiempo de ejecución no pueden cambiar valores ya escritos en `out/`. Para variables públicas de compilación en un Dockerfile personalizado, declara los `ARG` necesarios antes de `RUN npm run build`; nunca coloques credenciales privadas en el paquete exportado. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de implementación del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/nuxt.mdx b/_locales/es/framework-guides/nuxt.mdx new file mode 100644 index 0000000..03a70ff --- /dev/null +++ b/_locales/es/framework-guides/nuxt.mdx @@ -0,0 +1,109 @@ +--- +description: "Despliega Nuxt en Lizard con el preset node-server de Nitro. Añade un script de inicio de producción, ejecuta el servidor generado en el puerto 3000 y comprueba las rutas y la configuración de runtime." +--- + + + +# Desplegar Nuxt en Lizard + +Ejecuta Nuxt en Lizard con el preset de `node-server` de Nitro. La compilación produce `.output/server/index.mjs`, y un proceso de Node.js sirve páginas y rutas del servidor en el puerto `3000`. Para un sitio generado en el puerto `80`, usa la receta estática de abajo. + + + +## Configurar la compilación de producción + +Usa la versión actual de Lizard CLI de [Preparar el proyecto](/framework-guides#prepare-the-project). La versión 0.3.95 excluye los metadatos de archivos de archivo de macOS durante las subidas. Si una versión anterior de CLI informa un error de ruta de `._*.ts`, actualiza la CLI y vuelve a subir. + +Establece el preset en `nuxt.config.ts`: + +```ts +export default defineNuxtConfig({ + nitro: { preset: 'node-server' }, +}); +``` + +Combina estos scripts en `package.json`, conservando cualquier otro script que necesite tu aplicación: + +```json +{ + "scripts": { + "dev": "nuxt dev", + "build": "nuxt build", + "start": "HOST=0.0.0.0 PORT=3000 node .output/server/index.mjs" + } +} +``` + +El script de inicio usa el shell de Linux en el contenedor de despliegue. lizardpack detecta la dependencia `nuxt` y ejecuta los scripts de compilación e inicio. Un proyecto nuevo de Nuxt puede no incluir `start`; añádelo en lugar de asumir que `nuxt dev` servirá la compilación de producción. + +| Ajuste | Valor | +|---|---| +| Compilar | `npm run build` | +| Server entry | `.output/server/index.mjs` | +| Start | `npm run start` | +| Puerto del servicio | `3000` | + + + +## Probar la aplicación compilada + +```bash +npm ci +npm run build +npm run start +``` + +Abre `http://localhost:3000`, solicita directamente una página interna y llama a una de tus rutas `server/api` si existe. Comprueba que la compilación informa el preset de servidor Node. Un preset de Nitro específico del proveedor puede producir un punto de entrada diferente. + + + +## Desplegar + +Después de la [configuración de la CLI](/framework-guides#prepare-the-project), ejecuta desde el directorio de la aplicación Nuxt: + +```bash +lizard init --name nuxt-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Mantén los archivos `.nuxt/`, `.output/`, `node_modules/` y `.env` fuera de la subida. Incluye el código fuente, la configuración y el lockfile. Las anulaciones existentes de compilación/inicio del servicio omiten la detección usada aquí; consulta el [orden de decisión de compilación](/concepts/build-pipeline#build-decision-order). + + + +## Configuración de runtime + +Declara la configuración de runtime en `runtimeConfig` y configura sus valores `NUXT_*` correspondientes para el servicio. Mantén los secretos fuera de `runtimeConfig.public`; la parte pública llega al navegador. Los valores usados para prerenderizar páginas siguen afectando a la compilación generada, así que comprueba tanto las rutas en tiempo de solicitud como las prerenderizadas después de un cambio. + +Usa [variables y secretos](/variables) para configurar el servicio y [almacenamiento y recuperación](/platform/storage-and-recovery) para datos duraderos. No trates una caché local o un archivo de sesión como almacenamiento compartido entre réplicas. + + + +## Solución de problemas + +Si el proceso informa que falta `.output/server/index.mjs`, revisa el preset y la salida de la compilación. Si informa que falta un script de inicio, añade el de arriba. Si el sitio nunca llega a estar healthy, comprueba el host y el puerto. + +Para un sitio Nuxt puramente generado, sirve `.output/public/` con un Dockerfile estático y un manejo correcto de rutas. No inicies esa salida con el comando Node de arriba. La [guía de despliegue de Nuxt](https://nuxt.com/docs/4.x/getting-started/deployment) explica las salidas Node y generadas; [rutas estáticas y 404](/framework-guides/static-routing) cubre la configuración del servidor estático de Lizard. + + + +## Generar un sitio estático + +Para HTML generado, sustituye el preset de Node por una configuración de prerenderizado explícita y cambia el script de compilación a `nuxt generate`: + +```ts +export default defineNuxtConfig({ + nitro: { + prerender: { crawlLinks: true, routes: ['/'] }, + }, +}); +``` + +Añade rutas no enlazadas o dinámicas a `routes` cuando el rastreador no pueda descubrirlas. Ejecuta `npm run build` y comprueba que existen `.output/public/index.html` y los archivos de tus rutas internas. En la prueba con Nuxt 4.5.2, mantener `preset: 'node-server'` mientras se cambiaba solo a `nuxt generate` produjo las páginas de fallback sin las rutas del sitio. Una compilación exitosa por sí sola no demostraba que la exportación contuviera el sitio. + +Usa el Dockerfile y la configuración de nginx de [rutas estáticas y 404](/framework-guides/static-routing), con el script de compilación `build`, el directorio de salida `.output/public` y el puerto del servicio `80`. El contenedor estático no ejecuta rutas de servidor de Nuxt ni lee la configuración de runtime para páginas ya generadas. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/react.mdx b/_locales/es/framework-guides/react.mdx new file mode 100644 index 0000000..9db84e4 --- /dev/null +++ b/_locales/es/framework-guides/react.mdx @@ -0,0 +1,83 @@ +--- +description: "Implementa una app de React creada con Vite en Lizard. Compila dist, sírvela en el puerto 80, configura las rutas del cliente y las variables públicas de la API, y comprueba la app implementada." +--- + + + +# Implementar React con Vite en Lizard + +Lizard compila una app de React que usa Vite y sirve su directorio `dist/` mediante nginx en el puerto `80`. Esta guía cubre una app renderizada en el navegador. Para páginas de React que necesitan un servidor, sigue la [guía de Next.js](/framework-guides/nextjs) o proporciona un servidor de producción para el framework de React que hayas elegido. + + + +## Preparar la compilación + +Usa un proyecto existente de React y Vite con un lockfile confirmado en el repositorio. Su archivo `package.json` necesita un script de compilación de producción: + +```json +{ + "scripts": { + "dev": "vite", + "build": "vite build", + "preview": "vite preview" + } +} +``` + +Si tu plantilla ejecuta comprobaciones de TypeScript antes de `vite build`, mantén esas comprobaciones. Conserva el directorio de salida predeterminado de Vite, `dist`. Un `build.outDir` personalizado necesita un Dockerfile correspondiente porque la ruta de detección estándar copia `dist`. + +| Ajuste | Valor | +|---|---| +| Detección | `vite` en dependencies o dev dependencies | +| Compilación | `npm run build` | +| Salida | `dist/` | +| Servidor de producción | nginx; no se necesita script de inicio de Node | +| Puerto del servicio | `80` | + + + +## Probar localmente + +```bash +npm ci +npm run build +npm run preview +``` + +Abre la URL de vista previa local y prueba una página que llame a tu API. El comando de vista previa comprueba la compilación localmente; no configures `vite preview` como comando de inicio de producción. Consulta [despliegue de Vite](https://vite.dev/guide/static-deploy.html). + + + +## Implementar el código fuente + +Después de la [configuración de CLI](/framework-guides#prepare-the-project), ejecuta esto desde el directorio que contiene `package.json`: + +```bash +lizard init --name react-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Sube el código fuente y el lockfile, excluyendo `node_modules/`, `dist/` y los secretos. Deja sin configurar las anulaciones de compilación/inicio del servicio para usar la ruta de detección estática. El contenedor de nginx escucha en el puerto 80 aunque los servidores de desarrollo y vista previa usen otros puertos. + + + +## Conectar una API + +Usa una variable pública como `VITE_API_URL` para la dirección HTTPS de la API accesible desde el navegador. Léela como `import.meta.env.VITE_API_URL`. Configura ese valor mediante [variables y secretos](/variables) y vuelve a compilar cuando cambie. Nunca expongas una URL de base de datos, una credencial de API ni una dirección de servicio solo interna mediante una variable `VITE_*`. + +Para una API en otro origen, configura sus orígenes permitidos para que incluyan la URL del frontend. Un hostname de servicio privado que funciona entre servicios de backend no se resolverá en el navegador de un visitante. + + + +## Verificar el enrutamiento + +Abre la app en vivo, sigue una ruta del cliente y luego recarga esa URL directamente. El servidor estático predeterminado vuelve a `index.html` para que el router del cliente pueda renderizar una ruta interna. Añade también una ruta para rutas desconocidas en la app de React. Ese fallback sigue devolviendo HTTP 200; usa [rutas estáticas y 404](/framework-guides/static-routing) para elegir una política del servidor para páginas que necesitan respuestas HTTP 404 reales. + +Si un recurso devuelve HTML o la página queda en blanco, revisa el `base` de Vite, la URL del recurso solicitada y el directorio de salida. Si la app nunca llega a estar healthy, comprueba que el puerto del servicio sea `80` y que una anulación antigua del comando de inicio no haya seleccionado una ruta de compilación diferente. + +Para páginas destinadas a aparecer en búsquedas, inspecciona la respuesta HTML inicial. Es posible que un shell renderizado en el navegador no contenga el texto que esperas que lea un motor de búsqueda o un motor de respuestas. Elige prerenderizado o un framework con servidor cuando necesites ese texto en la respuesta. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/framework-guides/static-routing.mdx b/_locales/es/framework-guides/static-routing.mdx new file mode 100644 index 0000000..1d02759 --- /dev/null +++ b/_locales/es/framework-guides/static-routing.mdx @@ -0,0 +1,107 @@ +--- +description: "Configura rutas de sitios estáticos en Lizard: sirve HTML generado, admite URLs limpias, devuelve HTTP 404 para páginas inexistentes y elige cuándo corresponde un fallback de SPA." +--- + + + +# Rutas estáticas y 404 + +Un sitio de contenido generado debe servir el HTML de cada ruta y devolver HTTP 404 para una página inexistente. Las nuevas compilaciones de lizardpack para Astro static, Docusaurus, VitePress, Hugo y SvelteKit adapter-static usan esa política. Las SPA de React y Vue mantienen el fallback `index.html` necesario para los enrutadores del navegador. + +La configuración personalizada de abajo es opcional. Úsala para una política de enrutamiento que el framework detectado no proporcione. Las imágenes existentes conservan sus reglas anteriores hasta que las vuelvas a compilar. + + + +## Elige la política de enrutamiento + +| Tipo de app | Comportamiento de ruta | +|---|---| +| SPA de React o Vue | Una ruta de cliente válida carga `index.html`, y luego el enrutador del cliente la renderiza. | +| Documentación o contenido generado | Una ruta se resuelve a su HTML generado; una ruta desconocida devuelve HTTP 404. | +| App renderizada en servidor | El servidor de la aplicación resuelve las rutas y devuelve el estado. | + +Una vista comodín de SPA puede mostrar un mensaje de página inexistente, pero el código del navegador no puede cambiar el estado HTTP de la respuesta HTML que ya se envió. Si necesitas un estado HTTP según la ruta para una SPA, usa un servidor o una configuración de rutas prerenderizadas que conozca qué rutas existen. + + + +## Configura nginx para páginas generadas + +Crea `nginx.conf` en la raíz de la aplicación: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + + location / { + try_files $uri $uri.html $uri/ =404; + } + + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +Esto admite tanto los diseños de salida `guide.html` como `guide/index.html`. Incluye un `404.html` generado si quieres una página de error personalizada. De lo contrario, omite los bloques `error_page` y de ubicación exacta para usar el cuerpo de error predeterminado de nginx. Mantén un único estilo de URL canónica en los enlaces y el sitemap del sitio; esta regla de búsqueda no agrega redirecciones canónicas. + + + +## Compila el sitio con la configuración + +Usa este Dockerfile completo para un proyecto npm con un lockfile confirmado en el repositorio. Cambia los valores predeterminados de `BUILD_SCRIPT` y `OUTPUT_DIR` para que coincidan con la tabla de abajo: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +ARG BUILD_SCRIPT=build +RUN npm run "$BUILD_SCRIPT" + +FROM nginx:alpine +ARG OUTPUT_DIR=dist +COPY --from=build /app/${OUTPUT_DIR}/ /usr/share/nginx/html/ +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +| Sitio | `BUILD_SCRIPT` | `OUTPUT_DIR` | +|---|---|---| +| Astro static | `build` | `dist` | +| Docusaurus | `build` | `build` | +| VitePress con una raíz `docs/` | `docs:build` | `docs/.vitepress/dist` | +| VitePress en la raíz del proyecto | `docs:build` o tu script real | `.vitepress/dist` | +| SvelteKit con adapter-static | `build` | `build` | +| Next.js export | `build` | `out` | +| Nuxt generate | `build` con `nuxt generate` | `.output/public` | + +Usa la política de páginas generadas solo cuando la app tenga esos archivos de ruta. Un fallback de SPA de SvelteKit, por ejemplo, necesita su propia política de enrutamiento. [Exportación estática de Next.js](/framework-guides/nextjs/static-export) tiene una receta completa con un diseño de barra final. + +Excluye dependencias, salida de compilación, `.git` y `.env*` en `.dockerignore`. Si la compilación necesita variables públicas, declara sus valores de `ARG` antes del comando de compilación. No copies secretos privados en la imagen ni en la salida del navegador. + +Después de la [configuración de CLI](/framework-guides#prepare-the-project), crea un servicio con `lizard add --service web` y luego despliega este código fuente con `lizard up --service web --port 80`. Omite el paso de agregar cuando el servicio ya exista. En un servicio existente, revisa el [orden de decisión de compilación](/concepts/build-pipeline#build-decision-order): las anulaciones de comandos pueden tener prioridad sobre el Dockerfile. Un archivo de configuración por sí solo no reemplaza la configuración generada de nginx; el Dockerfile debe copiarlo a la imagen. + + + +## Verifica las respuestas HTTP + +Establece `SITE_URL` con la URL real de prueba local o el origen desplegado, y luego reemplaza `/guide/` por una página que exista: + +```bash +SITE_URL=https://YOUR_PUBLIC_HOST +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/guide/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/this-page-does-not-exist" +``` + +Espera 200 para páginas reales y 404 para la ruta inexistente. Si una ruta válida redirige a su forma canónica, inspecciona la redirección y luego verifica el destino. Prueba también un recurso real y una ruta inventada `.js`: un script inexistente no debe devolver la página de inicio como HTML con estado 200. + +Por último, abre la ruta interna directamente en un navegador y vuelve a cargarla. Una navegación correcta del cliente por sí sola puede ocultar un error de enrutamiento del servidor. Revisa la URL canónica y la configuración del sitemap del framework junto con el estado HTTP antes de publicar un sitio indexado. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. + diff --git a/_locales/es/framework-guides/sveltekit.mdx b/_locales/es/framework-guides/sveltekit.mdx new file mode 100644 index 0000000..9b6c9d6 --- /dev/null +++ b/_locales/es/framework-guides/sveltekit.mdx @@ -0,0 +1,110 @@ +--- +description: "Despliega SvelteKit en Lizard con adapter-node. Configura la compilación de producción, el puerto 3000, ORIGIN, las acciones de formularios y la ruta separada de adapter-static." +--- + + + +# Desplegar SvelteKit en Lizard + +Usa `@sveltejs/adapter-node` para compilar un servidor SvelteKit para Lizard. Produce `build/`, que se inicia con `node build` en el puerto `3000`. Instala y configura el adaptador de forma explícita; un proyecto base que todavía usa `adapter-auto` no establece un destino de despliegue Node. + +Empieza con el [ejemplo completo del código fuente](https://github.com/lizard-build/docs/tree/main/_examples/sveltekit), que incluye la configuración y los archivos usados por esta guía. + + + +## Configurar el adaptador + +```bash +npm install --save-dev @sveltejs/adapter-node +``` + +En `svelte.config.js`, mantén tu preprocess actual y los demás ajustes, pero establece `kit.adapter` en el adaptador Node: + +```js +import adapter from '@sveltejs/adapter-node'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +Conserva solo el adaptador de despliegue que realmente vayas a usar. En particular, una dependencia `@sveltejs/adapter-static` sin usar puede seleccionar la ruta estática en el detector actual incluso cuando tu configuración importa adapter-node. + +| Ajuste | Valor | +|---|---| +| Compilación | `npm run build`, normalmente `vite build` | +| Salida | `build/` | +| Entorno de ejecución | `node build` | +| Host y puerto | `HOST=0.0.0.0`, `PORT=3000` | +| Puerto del servicio | `3000` | + + + +## Probar el servidor de producción + +```bash +npm ci +npm run build +HOST=0.0.0.0 PORT=3000 ORIGIN=http://localhost:3000 node build +``` + +Abre una página renderizada en el servidor y envía una acción de formulario si la app tiene una. Mantén la ruta de salida predeterminada del adaptador para la detección usada en esta guía. + + + +## Desplegar y establecer el origen público + +Después de la [configuración de la CLI](/framework-guides#prepare-the-project): + +```bash +lizard init --name sveltekit-app +lizard add --service web +lizard up --service web --port 3000 +lizard ps --json +``` + +Establece `ORIGIN` con el origen HTTPS público exacto de la salida del despliegue, sin una ruta. Por ejemplo, reemplaza este marcador con tu URL real: + +```bash +lizard secrets set ORIGIN=https://YOUR_PUBLIC_HOST --service web +``` + +Usa el dominio personalizado en su lugar si ese es el origen que usarán los visitantes. Vuelve a comprobar los formularios después de cambiar la variable. Si necesitas varios orígenes permitidos o URL derivadas de proxy, lee la [guía del servidor Node de SvelteKit](https://svelte.dev/docs/kit/adapter-node) y configura deliberadamente los encabezados de proxy de confianza. + + + +## Verificar y solucionar problemas + +Lee los logs de compilación y ejecución con `lizard logs --build --service web --json` y `lizard logs --service web --json`. Abre directamente una ruta interna, envía un formulario y solicita una ruta inexistente. + +Si los formularios muestran un error de envío entre sitios, revisa `ORIGIN` antes de desactivar una comprobación de seguridad. Si `node build` no puede encontrar el servidor, verifica el adaptador activo y la ruta de salida. Deja sin configurar las anulaciones del comando del servicio para usar la ruta de lizardpack. + + + +## Sitios estáticos de SvelteKit + +Una app que pueda prerenderizar todas las páginas necesarias puede usar `@sveltejs/adapter-static`, su salida predeterminada `build/` y el puerto de servicio `80`. Esa salida no puede ejecutar acciones de servidor ni endpoints en tiempo de solicitud. Configura el prerenderizado para las rutas que necesites; instalar el paquete por sí solo no es suficiente. + +Instala `@sveltejs/adapter-static` y reemplaza la importación del adaptador en `svelte.config.js`: + +```js +import adapter from '@sveltejs/adapter-static'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +Para un sitio cuyas rutas puedan generarse por completo, añade esto a `src/routes/+layout.js`: + +```js +export const prerender = true; +export const trailingSlash = 'always'; +``` + +Elimina de las dependencias los adaptadores de despliegue que no uses. Ejecuta `npm run build` y comprueba que `build/` contiene cada página necesaria. Para la salida predeterminada, deja sin configurar las anulaciones del comando del servicio y despliega un servicio nuevo en el puerto `80`. Las compilaciones nuevas sirven el HTML generado y devuelven HTTP 404 para las páginas inexistentes. No reutilices el puerto `3000` de la receta del servidor para nginx. + +Usa [rutas estáticas y 404](/framework-guides/static-routing) para elegir entre rutas HTML generadas y una reserva SPA. Consulta [el adaptador estático de SvelteKit](https://svelte.dev/docs/kit/adapter-static) para ver las opciones y limitaciones del framework. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para ver las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. + diff --git a/_locales/es/framework-guides/validation.mdx b/_locales/es/framework-guides/validation.mdx new file mode 100644 index 0000000..47d27ec --- /dev/null +++ b/_locales/es/framework-guides/validation.mdx @@ -0,0 +1,72 @@ +--- +description: "Resultados de la guía de frameworks de 16 despliegues reales con Lizard CLI el 9 de septiembre de 2026: versiones probadas, rutas, formularios, migraciones, URL canónicas y límites." +--- + + + +# Resultados de pruebas de la guía de frameworks + +El 9 de septiembre de 2026, las 16 recetas de 11 frameworks superaron una compilación local y un nuevo despliegue en la nube con Lizard CLI 0.3.95. Seguimos la configuración publicada, creamos un proyecto y un servicio nuevos para cada receta y subimos el código fuente con `lizard up`. Estos resultados cubren las versiones y las pequeñas apps de prueba indicadas abajo. + +La ejecución en la nube superó 100 comprobaciones de rutas, API y formularios, además de 45 comprobaciones de archivos JavaScript y CSS enlazados. También superaron las migraciones de Django, una escritura y lectura en la base de datos, y las URL finales de los sitios de Docusaurus y Hugo. + + + +## Recetas probadas + +| Receta | Versiones probadas | Puerto | Comprobación en la nube | +|---|---|---|---| +| Next.js server | Next.js 16.3.4, React 19.2.8 | `3000` | Superado | +| Exportación estática de Next.js | Next.js 16.3.4, React 19.2.8 | `80` | Superado | +| React with Vite | React 19.2.8, Vite 8.2.2 | `80` | Superado | +| Vue with Vite | Vue 3.5.42, Vue Router 5.3.1, Vite 8.2.2 | `80` | Superado | +| Astro static | Astro 7.3.1 | `80` | Superado | +| Servidor Node de Astro | Astro 7.3.1, Node adapter 11.1.5 | `3000` | Superado | +| Nuxt Node server | Nuxt 4.5.2 | `3000` | Superado | +| Nuxt generate | Nuxt 4.5.2 | `80` | Superado | +| Servidor Node de SvelteKit | SvelteKit 2.70.3, Svelte 5.57.0, adapter-node 5.5.7 | `3000` | Superado | +| SvelteKit static | SvelteKit 2.70.3, Svelte 5.57.0, adapter-static 3.0.10 | `80` | Superado | +| Docusaurus | Docusaurus 3.10.2 | `80` | Superado | +| VitePress, raíz de docs | VitePress 1.6.4 | `80` | Superado | +| VitePress, raíz del proyecto | VitePress 1.6.4 | `80` | Superado | +| FastAPI | FastAPI 0.141.1, Uvicorn 0.52.4 | `8000` | Superado | +| Django | Django 6.1.1, Gunicorn 26.2.0, WhiteNoise 6.12.0, psycopg 3.3.5 | `8000` | Superado | +| Hugo | Hugo 0.165.0 (extended) | `80` | Superado | + +Las compilaciones de JavaScript usaron Node 22; las compilaciones de Python usaron Python 3.13. Las subidas se ejecutaron desde macOS sin `COPYFILE_DISABLE`. Los manifiestos de paquetes y lockfiles fijan las versiones indicadas arriba. Las etiquetas de imagen de contenedor pueden cambiar de forma independiente de un lockfile de paquetes. + + + +## Qué comprobamos el 9 de septiembre + +- Ejecutamos los comandos documentados de compilación local y servidor en contenedores Linux, luego ejecutamos `lizard init`, `lizard add` y `lizard up` para cada receta. Leímos los logs de compilación y ejecución en la nube y comprobamos el estado final del servicio y el puerto. +- Solicitamos la página de inicio pública, una ruta interna, un recurso real, una página inexistente y una ruta de JavaScript inexistente. Los sitios de contenido estático devolvieron 404 reales; React y Vue mantuvieron su fallback SPA documentado. Ambos diseños de VitePress devolvieron el contenido correcto en URL limpias. +- Comprobamos respuestas de API en tiempo de solicitud, manejadores POST, resultados de formularios de SvelteKit y el rechazo de un formulario desde un origen no confiable. Enviamos el formulario desplegado de Next.js Server Acción por HTTP usando su ID de acción generado y comprobamos la redirección y el valor devuelto. +- Volvimos a compilar Docusaurus y Hugo después de configurar el hostname generado en la configuración. Las URL canónicas de Docusaurus y ambos sitemaps usaron el host público. +- Ejecutamos las migraciones de Django contra Managed Postgres dos veces, escribimos y leímos una fila de prueba, servimos archivos estáticos recopilados, aceptamos un formulario CSRF válido y rechazamos un formulario sin su token. + +Cada receta usó un proyecto de prueba independiente, con nombres distintos para mantener la ejecución aislada. Espacio de trabajo, region y las flags JSON hicieron explícito el contexto de prueba. Los overrides de servicio de compilación, inicio y ruta de Dockerfile se dejaron sin configurar. Solo las recetas de Exportación estática de Next.js, Nuxt generate y Django proporcionaron los Dockerfiles documentados en sus guías. Las pruebas de Docusaurus, VitePress, Hugo y SvelteKit Node incluyeron los [ejemplos de código publicados](https://github.com/lizard-build/docs/tree/main/_examples). + + + +## Comprobaciones en navegador + +La ejecución del 9 de septiembre confirmó un clic en un botón de React en el navegador. Luego, la conexión del navegador devolvió timeouts repetidos durante la navegación y la lectura de páginas, por lo que esta ejecución **no** afirma una nueva validación en navegador para las 16 recetas. Las comprobaciones de rutas HTTP y formularios se superaron de forma independiente. + +La ejecución del 7 de septiembre incluyó recargas directas de rutas, interacción con React, navegación con Vue Router, Next.js Server Actions y envíos de formularios de SvelteKit en un navegador. Esos siguen siendo resultados de esa ejecución anterior. + + + +## Correcciones desde la primera ejecución + +La ejecución del 7 de septiembre encontró pasos faltantes de creación de servicios, una incompatibilidad del preset estático de Nuxt, defectos de enrutamiento estático, metadatos de archivo macOS, códigos de salida de compilación fallida y errores de cambio de puerto. Las guías ahora incluyen `lizard add` y la configuración estática corregida de Nuxt. + +La reverificación del enrutamiento estático del 8 de septiembre se superó sin Dockerfiles personalizados para Astro static, SvelteKit static, Docusaurus, Hugo y ambos diseños de VitePress. Las compilaciones nuevas incluyen esas reglas de enrutamiento; las imágenes existentes necesitan una recompilación. + +Lizard CLI 0.3.95 incluye las correcciones del archivo y de los códigos de salida de compilación fallida. Las comprobaciones de producción del 9 de septiembre también verificaron cambios del puerto del servicio y la conservación de un puerto explícito durante la subida y la recompilación. Consulta [problemas conocidos](/platform/known-issues) para ver las notas de la versión y los límites restantes. + + + +## Límites de estos resultados + +Estas comprobaciones cubren las subidas de código fuente y los modos documentados. No establecen compatibilidad con cada plugin, adapter, tema, versión de framework, ruta de despliegue de GitHub, procedimiento de recuperación de base de datos o carga de trabajo con múltiples réplicas. La pequeña app de prueba de Django sigue mostrando advertencias de seguridad de `check --deploy`; no es una configuración de seguridad de producción completa. Estas pruebas no miden rankings de búsqueda ni citas de IA. Comprueba las rutas y operaciones de datos de tu propia app antes del lanzamiento. diff --git a/_locales/es/framework-guides/vitepress.mdx b/_locales/es/framework-guides/vitepress.mdx new file mode 100644 index 0000000..37f0941 --- /dev/null +++ b/_locales/es/framework-guides/vitepress.mdx @@ -0,0 +1,78 @@ +--- +description: "Despliega VitePress en Lizard con docs:build, el directorio correcto .vitepress/dist, nginx y el puerto 80. Configura URLs limpias y verifica las rutas de documentación y los 404." +--- + + + +# Desplegar VitePress en Lizard + +Lizard puede compilar un sitio de documentación de VitePress y servir el HTML generado mediante nginx en el puerto `80`. Haz coincidir el script de npm y el directorio de salida con la raíz de tu documentación: `vitepress build docs` escribe en `docs/.vitepress/dist`, mientras que `vitepress build` escribe en `.vitepress/dist`. + +Empieza con el [ejemplo completo del código fuente](https://github.com/lizard-build/docs/tree/main/_examples/vitepress), que incluye la configuración y los archivos usados por esta receta. + + + +## Configurar el script de compilación + +Para archivos Markdown en `docs/`, conserva estos scripts en `package.json`: + +```json +{ + "scripts": { + "docs:dev": "vitepress dev docs", + "docs:build": "vitepress build docs", + "docs:preview": "vitepress preview docs" + } +} +``` + +| Ajuste | Valor en esta guía | +|---|---| +| Compilación | `npm run docs:build` | +| Raíz de la documentación | `docs/` | +| Salida | `docs/.vitepress/dist/` | +| Servidor de producción | nginx | +| Puerto del servicio | `80` | + +El detector encuentra un script que contiene `vitepress build` y usa su argumento de raíz. Mantén ese script directo y sin ambigüedades. Los envoltorios de shell, varios scripts coincidentes o un `outDir` personalizado requieren una configuración de compilación explícita o un Dockerfile. + + + +## Comprobar el sitio localmente + +```bash +npm ci +npm run docs:build +npm run docs:preview +``` + +Comprueba una página Markdown interna y un recurso. Con `cleanUrls: true`, VitePress enlaza a rutas sin extensión; el servidor de producción debe resolver esas URLs a los archivos HTML generados. Configura `base` con el prefijo de ruta real, o `/` para la raíz del dominio. Consulta [despliegue de VitePress](https://vitepress.dev/guide/deploy). + + + +## Desplegar + +Después de la [configuración de CLI](/framework-guides#prepare-the-project), ejecuta desde el directorio que contiene `package.json`, no desde dentro de `docs/`: + +```bash +lizard init --name vitepress-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Incluye la configuración de VitePress, Markdown, recursos fuente, el manifiesto del paquete y el lockfile. Excluye las dependencias locales, la salida generada, las cachés y los secretos. No establezcas `vitepress dev` ni `vitepress preview` como comando de inicio del servicio. + + + +## Comprobar rutas limpias y estado HTTP + +Las compilaciones nuevas de VitePress resuelven las rutas sin extensión a sus archivos `.html` generados y devuelven HTTP 404 para URLs inexistentes. Mantén las anulaciones de comandos sin configurar para usar esta ruta de detección. No se necesita un Dockerfile personalizado para la salida estándar. Consulta [rutas estáticas y 404](/framework-guides/static-routing) para el enrutamiento personalizado. + +Comprueba directamente una URL limpia y recárgala. Solicita una ruta que no exista y confirma HTTP 404. Si una imagen anterior sirve la página de inicio para rutas inexistentes, vuelve a compilar el servicio para aplicar las reglas de enrutamiento actuales. + +Si la compilación informa `Missing script: build`, comprueba que la ruta seleccionada use el detector de VitePress y que ninguna anulación de comando del servicio lo reemplace. Si la compilación se completa correctamente pero nginx no sirve la documentación, compara la raíz de documentación del script con el directorio de salida copiado. Vuelve a compilar después de cambios en el contenido o la configuración. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. + diff --git a/_locales/es/framework-guides/vue.mdx b/_locales/es/framework-guides/vue.mdx new file mode 100644 index 0000000..d125482 --- /dev/null +++ b/_locales/es/framework-guides/vue.mdx @@ -0,0 +1,70 @@ +--- +description: "Despliega una app de Vue creada con Vite en Lizard. Configura la salida dist, el puerto 80, el modo history de Vue Router, las variables de entorno públicas y las comprobaciones de producción." +--- + + + +# Desplegar Vue con Vite en Lizard + +Despliega una app de Vue creada con Vite como un servicio web estático en Lizard. La compilación genera `dist/`, y nginx sirve los archivos en el puerto `80`. Para renderizado del lado del servidor con Nuxt y rutas de servidor, usa la [guía de Nuxt](/framework-guides/nuxt). + + + +## Preparar el proyecto + +Ejecuta esto desde el directorio de la app de Vue con `package.json`, un lockfile y la configuración de Vite. Mantén el script de compilación del scaffold, incluido `vue-tsc` si comprueba tu código TypeScript. La compilación debe terminar generando el bundle de Vite en `dist/`. + +| Ajuste | Valor | +|---|---| +| Compilar | `npm run build` | +| Output | `dist/` | +| Start command | Ninguno para la ruta de detección estática | +| Puerto del servicio | `80` | + +Mantén `base: '/'` para un sitio en la raíz del dominio. Si usas un prefijo de ruta, alinea la base de Vite con la base del router y con la URL donde realmente se ejecuta la app. Un directorio de salida personalizado necesita un Dockerfile que copie ese directorio. + + + +## Comprobar la compilación localmente + +```bash +npm ci +npm run build +npm run preview +``` + +Usa la URL de vista previa local para comprobar un componente que obtiene datos y una página a la que se llega mediante el router. `vite preview` es para esta comprobación local; nginx sirve los archivos de producción. Consulta la [guía de despliegue de Vite](https://vite.dev/guide/static-deploy.html) para ver el comportamiento de la salida de compilación y de la vista previa. + + + +## Desplegar + +Después de la [configuración de la CLI](/framework-guides#prepare-the-project), despliega el directorio fuente actual: + +```bash +lizard init --name vue-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Excluye las dependencias locales, los archivos `dist/` y `.env` de la subida. Si no hay sobrescrituras de comandos existentes, lizardpack detecta Vite y crea la imagen estática. No añadas `npm run dev` como comando de inicio del servicio. + + + +## Modo history de Vue Router + +Si tu app usa `createWebHistory`, su servidor debe manejar las solicitudes directas a rutas del cliente. La imagen estática predeterminada sirve `index.html` cuando no puede encontrar un archivo, por lo que `/account` puede llegar a Vue Router en una recarga completa. Haz que la base del router coincida con la base de Vite, por ejemplo con `createWebHistory(import.meta.env.BASE_URL)`. Consulta [los modos history de Vue Router](https://router.vuejs.org/guide/essentials/history-mode.html). + +Prueba tanto la navegación desde la página de inicio como abrir `/account` en una pestaña nueva. Añade una vista comodín para las rutas de cliente que no existan. El fallback del servidor devuelve HTTP 200 incluso para rutas desconocidas; no proporciona respuestas 404 adecuadas para buscadores. Lee [rutas estáticas y 404](/framework-guides/static-routing) antes de usar esta configuración para un sitio de contenido indexado. + + + +## Variables y solicitudes a la API + +Vite escribe los valores `VITE_*` en el bundle del navegador durante la compilación. Úsalos solo para valores públicos, como la URL pública HTTPS de tu API. Configúralos mediante [variables y secretos](/variables), y luego comprueba la solicitud de red real de la app recompilada. Un reinicio solo en tiempo de ejecución no puede reemplazar un valor dentro del JavaScript ya compilado. + +Si las solicitudes fallan solo después del despliegue, comprueba CORS en la API y confirma que el navegador no esté llamando a `localhost` ni a un hostname privado del backend. Si el HTML carga pero fallan los recursos, inspecciona la base de Vite y las rutas de los recursos. Para páginas que necesitan HTML antes de que se ejecute JavaScript, elige el renderizado de Nuxt o un paso explícito de prerenderizado. + +Consulta [versiones probadas y resultados en la nube](/framework-guides/validation) para las comprobaciones de despliegue del 9 de septiembre de 2026 y sus límites. diff --git a/_locales/es/getting-started.mdx b/_locales/es/getting-started.mdx new file mode 100644 index 0000000..9caedd0 --- /dev/null +++ b/_locales/es/getting-started.mdx @@ -0,0 +1,134 @@ +--- +description: "Instala la Lizard CLI, inicia sesión y lanza tu primera app desde un repositorio de GitHub o una carpeta local en unos minutos; luego añade una base de datos." +--- + + + +# Inicio rápido de apps + +Lanza tu primera app en Lizard en unos minutos. Necesitarás Node.js 18+ y npm; se crea una cuenta de Lizard automáticamente la primera vez que `lizard login`. Instalarás la CLI, iniciarás sesión y desplegarás, ya sea directamente desde un repositorio de GitHub o desde un directorio local. + + + +## 1. Instala la CLI + +Instala globalmente desde npm el binario `lizard`: + +```bash +npm install -g @lizard-build/cli +``` + +Verifica que esté en tu `PATH`: + +```bash +lizard --version +``` + +> **No uses `npx`.** Usa siempre el binario `lizard` instalado globalmente. Ejecutar `npx @lizard-build/cli` descarga una copia temporal cuya versión puede diferir de la plataforma. Más adelante, actualízalo en el mismo lugar con `lizard upgrade`. + +> **¿Errores de permisos (EACCES)?** No uses `sudo`. Haz que npm apunte a un prefijo propiedad de tu usuario: +> ```bash +> mkdir -p ~/.npm-global +> npm config set prefix ~/.npm-global +> echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc && source ~/.zshrc +> npm install -g @lizard-build/cli +> ``` + + + +## 2. Inicia sesión + +```bash +lizard login +``` + +Esto abre tu navegador para autenticarte y luego vuelve a tu terminal una vez que confirmes. En CI u otros entornos no interactivos, autentícate con un token en su lugar: + +```bash +export LIZARD_TOKEN=lzd_xxx +# or +lizard login --token lzd_xxx +``` + +Comprueba quién eres en cualquier momento: + +```bash +lizard whoami +``` + + + +## 3. Despliega + +Elige la ruta que coincida con dónde vive tu código. + + + +### Opción A — Desplegar un repositorio de GitHub (recomendado) + +Si tu código está en GitHub, crea un servicio directamente desde el repositorio. Lizard lo clona, detecta automáticamente el stack, lo compila y devuelve una URL activa: + +```bash +lizard add -r your-org/your-app +``` + +A partir de entonces, los pushes a la rama seguida volverán a desplegar automáticamente. Para repositorios privados, conecta primero la GitHub App: + +```bash +lizard git connect +``` + + + +### Opción B — Desplegar código local + +Desde dentro del directorio de tu proyecto, sube y despliega la carpeta actual (respeta `.gitignore`): + +```bash +lizard up +``` + +Si el directorio aún no está vinculado a un proyecto, `up` creará o seleccionará uno de forma interactiva. En CI, vincúlalo explícitamente primero con `lizard init --name my-project`. + +De cualquier forma, cuando termine la compilación obtendrás una URL generada como `https://your-app-production.onlizard.com`. + + + +## 4. Observa cómo compila y se ejecuta + +```bash +lizard ps # services in the project, with status + URL +lizard logs # last runtime log lines +lizard logs --build # the most recent build's logs +lizard open # open the project in the dashboard +``` + + + +## 5. Añade una base de datos (opcional) + +Aprovisiona un Managed Postgres y haz referencia a él desde tu servicio: + +```bash +lizard add postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service your-app +lizard redeploy --service your-app +``` + +La referencia `${{postgres.DATABASE_URL}}` se resuelve en el momento del despliegue y rota automáticamente con el addon. Consulta [Managed Addons](/addons). + + + +## Siguientes pasos + +- **[Conceptos básicos](/concepts/architecture)** — entiende los proyectos, servicios y el pipeline de compilación. +- **[Desplegar desde GitHub](/deploy/github)** — ramas, monorepos y redespliegues automáticos. +- **[Variables y secretos](/variables)** — alcance y precedencia. +- **[Redes](/networking)** — adjunta tu propio hostname con TLS automático. +- **[Desplegar una app que creó tu IDE con IA](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production)** — los mismos tres pasos, pero entregados a un agente en su lugar, para una app escrita en Google Antigravity. + + + +## Costes de hosting + +Lizard usa [pay as you go](/platform/billing) sin suscripción mensual. El uso de recursos se descuenta de tu saldo de cuenta. Los créditos comprados no caducan; los créditos de prueba sí. Consulta los [precios](https://lizard.build/pricing) y los límites de tu cuenta antes de desplegar. diff --git a/_locales/es/guides/_meta.ts b/_locales/es/guides/_meta.ts new file mode 100644 index 0000000..0adbc5c --- /dev/null +++ b/_locales/es/guides/_meta.ts @@ -0,0 +1,2 @@ +export default { index: "Elige una guía", 'deploy-from-coding-agent': "Desplegar desde un agente de programación", 'deploy-mcp-server': "Alojar un servidor MCP remoto", 'telegram-bot': "Ejecutar un bot de Telegram", umami: "Ejecutar Umami", flowise: "Ejecutar Flowise con PostgreSQL", validation: "Resultados de las pruebas" }; + diff --git a/_locales/es/guides/deploy-from-coding-agent.mdx b/_locales/es/guides/deploy-from-coding-agent.mdx new file mode 100644 index 0000000..461f667 --- /dev/null +++ b/_locales/es/guides/deploy-from-coding-agent.mdx @@ -0,0 +1,139 @@ +--- +description: "Despliega una app desde Claude Code, Codex o Cursor con Lizard Skill y Lizard CLI. Elige GitHub o código fuente local, conecta una base de datos y verifica el resultado." +--- + + + +# Desplegar desde un agente de código + +Un agente de código puede usar Lizard Skill y Lizard CLI para desplegar la app que ha creado. El agente lee la guía del CLI instalado, revisa el proyecto de destino, ejecuta la compilación e inspecciona el resultado. Esto no requiere un transporte MCP independiente. + + + +## Antes de empezar + +Ten una aplicación funcional, permiso para desplegarla y una cuenta en Lizard. La aplicación debe escuchar en `0.0.0.0` y el puerto configurado. Ejecuta sus comprobaciones locales antes de iniciar una compilación en la nube. + + + +## Da al agente la guía actual + +```bash +npm install -g @lizard-build/cli +lizard skills get core --json +lizard --help --json +``` + +Lizard Skill carga instrucciones que coinciden con el CLI instalado. Para un comando concreto, lee su esquema en lugar de adivinar las opciones: + +```bash +lizard up --help --json +lizard service set --help --json +``` + +Un prompt útil es: + +> Despliega esta app con Lizard. Lee la guía del CLI instalado, revisa el proyecto y el servicio vinculados, ejecuta las comprobaciones de la app y muestra el resultado de la compilación y una URL funcional. Pregunta antes de cambiar un servicio de producción existente o eliminar datos. + + + +## Desplegar código fuente local + +Para una prueba completa, usa el [ejemplo agent-app](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/agent-app). Usa Node.js 22 y `pg` 8.16.3, escucha en el puerto 3000 y lee una fila de Managed Postgres. Al iniciarse, crea la tabla y la fila de demostración si no existen. Para una aplicación más grande, usa tu propio proceso de migración. + +Copia el ejemplo en su propio directorio y ejecuta sus comprobaciones locales: + +```bash +npm ci +npm run check +lizard status --json +``` + +Esto comprueba la sintaxis de JavaScript. Las comprobaciones de la base de datos y del HTTP público vienen después del despliegue. Si este directorio ya está vinculado, revisa que sea el proyecto previsto. Para un proyecto de prueba nuevo: + +```bash +lizard init --name agent-example --json +lizard add --service api --json +lizard add postgres --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api --json +lizard up --service api --port 3000 --json +``` + +Usa el nombre real de la base de datos si no es `postgres`. Mantén la referencia entre comillas para que el shell local no la expanda. Configúrala antes del primer despliegue. Inicia sesión con `lizard login` solo si un comando indica que se requiere autenticación. + +La ruta de carga es intencional para este ejemplo copiado. Para una aplicación que ya está en GitHub, usa la siguiente sección. En macOS con Lizard CLI 0.3.92, ejecuta `COPYFILE_DISABLE=1 lizard up --service api --port 3000 --json` para excluir metadatos AppleDouble. En esa versión del CLI, una compilación fallida aún puede salir con código 0: inspecciona el evento de terminal `failed`/`deployed` y verifica la aplicación. Consulta [problemas conocidos](/platform/known-issues). + + + +## Desplegar desde GitHub + +Usa esta ruta cuando la aplicación tenga un repositorio de GitHub. Revisa primero el remoto: + +```bash +git remote get-url origin +lizard status --json +lizard ps --json +``` + +Usa un proyecto de prueba vinculado o crea uno con `lizard init --name YOUR_PROJECT_NAME`. Adjunta el repositorio sin iniciar una compilación para tener tiempo de configurar su entorno: + +```bash +lizard add --repo YOUR_ORG/YOUR_REPO --name api-git --no-deploy --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api-git --json +``` + +Primero aprovisiona Managed Postgres si este proyecto no lo tiene. Esta secuencia usa el mismo ejemplo de Node.js de arriba. Para un repositorio con esa app en un subdirectorio o en otra rama, configúralo antes del despliegue: + +```bash +lizard service set api-git --set branch=YOUR_BRANCH --set rootDirectory=YOUR_APP_DIRECTORY --set containerPort=3000 --json +lizard redeploy --service api-git --json +``` + +Para una app en la raíz del repositorio en `main`, omite el comando `service set`. Define el puerto correcto si tu aplicación usa otro. Si el repositorio no está disponible para Lizard, conecta la app de GitHub; no sustituyas esta ruta por una carga de forma silenciosa. + +Para actualizaciones posteriores de un servicio de GitHub existente, usa `lizard redeploy --service api-git` o haz push a su rama seguida cuando el despliegue automático esté habilitado. `lizard up` cambia un servicio para cargar código fuente. Cambiar la configuración de compilación en un servicio que ya está en ejecución puede activar su propia compilación; inspecciona los eventos antes de solicitar otra. + + + +## Verificar el resultado + +Lee por separado los registros de compilación y de ejecución: + +```bash +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +Usa `api-git` en lugar de `api` para la ruta de GitHub. Define `APP_URL` con la URL HTTPS informada por el CLI y luego ejecuta: + +```bash +curl --fail "$APP_URL/health" +curl --fail "$APP_URL/data" +``` + +La primera respuesta es `App ready`. La segunda es `{"value":"database-connected"}`. Una compilación por sí sola no demuestra que la referencia a la base de datos se haya resuelto. El ejemplo expone solo esta fila fija de demostración, no una API de administración de bases de datos. + +Para este servicio de prueba, verifica un reinicio en tiempo de ejecución: + +```bash +lizard restart --service api --json +``` + +Espera a que el servicio vuelva a `running` en `lizard ps --json` y repite ambas solicitudes HTTP. El seguimiento de registros en tiempo de ejecución puede estar vacío; la respuesta HTTP es la comprobación de la aplicación. La fila se almacena en Managed Postgres; el proceso del servicio no la almacena. Para comprobar la reutilización de datos existentes, actualiza la fila de demostración a un valor distinto en el editor de base de datos antes del reinicio y confirma que `/data` devuelve ese valor después. + +`logs --json` devuelve un tail de logs y sale. Lee [almacenamiento y recuperación](/platform/storage-and-recovery) antes de cambiar datos reales de la aplicación. + + + +## Cuando el despliegue falla + +Usa el código de salida y el error JSON del comando fallido. Un error de compilación, un proceso que sale y un puerto inaccesible requieren soluciones distintas. Consulta [JSON y automatización](/cli/json) y [el servicio nunca está healthy](/deploy/troubleshooting/service-never-healthy). `redeploy` es una compilación nueva, no una reversión a una versión anterior. + + + +## Límites y coste + +Un agente puede crear recursos facturables mediante el mismo CLI que una persona. Revisa [límites](/platform/limits) y [precios](https://lizard.build/pricing), y limita las credenciales al proyecto y a los servicios que necesita. + +Consulta [resultados de pruebas de escenarios](/guides/validation) para ver las versiones comprobadas, los resultados en la nube y los límites restantes. diff --git a/_locales/es/guides/deploy-mcp-server.mdx b/_locales/es/guides/deploy-mcp-server.mdx new file mode 100644 index 0000000..9937154 --- /dev/null +++ b/_locales/es/guides/deploy-mcp-server.mdx @@ -0,0 +1,116 @@ +--- +description: "Aloja un servidor MCP remoto en Lizard con Streamable HTTP, comprobaciones de token bearer, un endpoint de estado y un cliente que verifica una llamada a herramienta." +--- + + + +# Alojar un servidor MCP remoto + +Implementa un servidor MCP como una aplicación HTTP cuando los clientes necesiten una URL remota. Este ejemplo sirve una herramienta aritmética, valida un token bearer y expone un endpoint de estado. Usa Streamable HTTP; un servidor local `stdio` no puede servir por sí solo a clientes remotos. + + + +## Antes de empezar + +Necesitas Node.js 22, Lizard CLI, un proyecto que puedas desplegar y un cliente MCP que acepte un token bearer configurado. El ejemplo usa `@modelcontextprotocol/sdk` 1.30.0 en modo stateless. No proporciona inicio de sesión OAuth, acceso desde navegador ni un proveedor de identidad. + +Los archivos ejecutables están en [remote-mcp-node](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/remote-mcp-node). Usa el lockfile incluido en el repositorio. La prueba local rápida comprueba la inicialización, el descubrimiento de herramientas, una llamada a herramienta y el rechazo sin un token válido. Una comprobación de despliegue también debe confirmar el proxy público y la ruta TLS. + + + +## Ejecutar localmente + +Desde el directorio del ejemplo: + +```bash +npm ci +npm test +node issue-token.mjs +export MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" +export MCP_ALLOWED_HOSTS=127.0.0.1,localhost +npm start +``` + +El token generado caduca después de una hora. La clave privada de firma no se guarda. Usa tu propio emisor de tokens y proceso de rotación para un despliegue duradero; mantén su clave privada fuera del servidor. + +En otra terminal: + +```bash +export MCP_URL=http://127.0.0.1:8000/mcp +export MCP_TOKEN="$(cat .mcp-token)" +node client.mjs +``` + +El cliente comprueba la inicialización, el descubrimiento de herramientas y el resultado `5`, y luego imprime `MCP initialize, tools/list and tools/call passed: 5`. `/health` devuelve `ok`; una solicitud a `/mcp` sin un token válido devuelve `401`. + + + +## Desplegar la aplicación + +Mantén el Dockerfile y el lockfile del ejemplo. Desde el directorio que los contiene: + +```bash +lizard init --name mcp-example +lizard add --service mcp +lizard domain --service mcp --json +``` + +Inicia sesión con `lizard login` si un comando informa de que se requiere autenticación. `init` vincula el proyecto; `add` crea el servicio con el nombre indicado. El comando de dominio asigna su nombre de host antes del despliegue. Usa el `hostname` devuelto abajo, sin `https://` ni una ruta: + +```bash +lizard secrets set MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" --service mcp +lizard secrets set MCP_ALLOWED_HOSTS=YOUR_SERVICE_HOSTNAME --service mcp +``` + +Configura ambos valores antes del primer despliegue. Luego ejecuta: + +```bash +lizard up --service mcp --port 8000 +lizard logs --build --service mcp --json +lizard logs --service mcp --json +lizard ps --json +``` + +En macOS con Lizard CLI 0.3.92, usa `COPYFILE_DISABLE=1 lizard up --service mcp --port 8000` para excluir metadatos AppleDouble del archivo. Una versión posterior de la CLI puede incluir la corrección del archivo. Comprueba el evento final del despliegue y el endpoint público; no dependas solo del código de salida de esta versión de la CLI después de una compilación fallida. `server.mjs` escucha en `0.0.0.0` y lee `PORT`, con 8000 como valor predeterminado. El comando de despliegue establece el puerto del servicio en 8000. Configura la clave pública como un valor de entorno multilínea; no subas la clave privada de firma ni el archivo del token. + + + +## Verificar el endpoint público + +Configura `MCP_URL` en `https://YOUR_SERVICE_HOSTNAME/mcp`, mantén un token válido en el entorno del cliente y ejecuta `node client.mjs`. Verifica los tres resultados: + +1. `/health` devuelve `200` a través de HTTPS. +2. `/mcp` rechaza a un cliente sin un token válido. +3. El cliente autenticado lista herramientas y llama a `add`, devolviendo `5`. + +Un proceso en buen estado por sí solo no demuestra que el handshake de MCP o la respuesta en streaming funcionen a través del proxy público. + + + +## Solución de problemas + +| Resultado | Comprobar | +|---|---| +| El proceso se cierra durante el arranque | `MCP_PUBLIC_KEY` debe contener la clave PEM pública; `MCP_ALLOWED_HOSTS` debe contener el nombre de host del servicio. | +| `401` | El token debe usar RS256, coincidir con el emisor y la audiencia `mcp-example`, y no haber caducado. | +| `403` | Haz coincidir el nombre de host de la solicitud con `MCP_ALLOWED_HOSTS`. Los orígenes de navegador no están habilitados en este ejemplo. | +| `405` con un token válido | Este endpoint MCP stateless acepta solicitudes del protocolo mediante POST. Usa un cliente MCP. Un GET desde navegador sin token devuelve primero `401`. | +| La prueba local pasa pero la llamada remota falla | Comprueba el puerto, HTTPS, el streaming de la respuesta y los tiempos de espera del proxy. | + + + +## Límites y coste + +Este ejemplo no mantiene sesiones de usuario ni archivos persistentes en la memoria del servidor. Añade una base de datos para el estado persistente de la aplicación y comprueba el acceso por usuario antes de exponer herramientas privadas. Para clientes que requieran descubrimiento OAuth o inicio de sesión interactivo, añade un proveedor de OAuth compatible en lugar de distribuir este token de prueba. + +Un proceso HTTP puede permanecer activo entre llamadas. Consulta [pricing](https://lizard.build/pricing), [limits](/platform/limits) y el uso medido de CPU/memoria; una cola de solicitudes vacía no implica que no haya cargos. + + + +## Siguientes pasos + +- [Referencias de entorno](/variables/references) +- [Recuperación de despliegues](/concepts/deployments) +- [Guía del servidor MCP TypeScript SDK](https://ts.sdk.modelcontextprotocol.io/server) + +Consulta [resultados de pruebas de escenario](/guides/validation) para ver las versiones comprobadas, los resultados en la nube y los límites restantes. diff --git a/_locales/es/guides/flowise.mdx b/_locales/es/guides/flowise.mdx new file mode 100644 index 0000000..a04885a --- /dev/null +++ b/_locales/es/guides/flowise.mdx @@ -0,0 +1,165 @@ +--- +description: "Implementa Flowise con PostgreSQL, conserva su clave de cifrado de credenciales y comprueba los flujos guardados después de reinicios y actualizaciones." +--- + + + +# Ejecutar Flowise con PostgreSQL + +Esta guía ejecuta un servicio de Flowise en Lizard, con PostgreSQL para flujos, cuentas y credenciales cifradas. Compila una versión exacta de npm y establece la clave de cifrado como un secreto del servicio. + +La configuración básica cubre flujos que usan APIs. Los archivos subidos y los almacenes vectoriales locales necesitan almacenamiento persistente aparte; consulta [Almacenamiento de archivos](#file-storage) antes de usar esas funciones. + + + +## Requisitos previos + +- Una cuenta de Lizard con acceso a alojamiento de aplicaciones y Managed Postgres. +- Node.js, npm y OpenSSL en tu computadora. +- Memoria suficiente para tu carga de trabajo de Flowise; el servicio de prueba usa 4 GiB. + +Instala Lizard CLI y completa el inicio de sesión en el navegador: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + + + +## Crear el proyecto + +```bash +mkdir flowise-on-lizard +cd flowise-on-lizard +lizard init --name flowise-on-lizard +lizard add postgres --name flowise-db +lizard add --service flowise +``` + +Usa `--workspace ` con `lizard init` si necesitas seleccionar un espacio de trabajo. Espera hasta que la base de datos esté en ejecución. + + + +## Compilar una versión fija de Flowise + +Crea `Dockerfile` con el contenido de abajo. Esto sigue la compilación de Docker de Flowise y fija el paquete npm en `3.1.4`: + +```dockerfile +FROM node:24-alpine AS build +RUN apk add --no-cache git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev +ENV PUPPETEER_SKIP_DOWNLOAD=true +RUN npm install -g flowise@3.1.4 --legacy-peer-deps + +FROM node:24-alpine +RUN apk add --no-cache chromium git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev curl +ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser +COPY --from=build /usr/local/lib/node_modules /usr/local/lib/node_modules +COPY --from=build /usr/local/bin /usr/local/bin +RUN chown -R node:node /usr/local/lib/node_modules /usr/local/bin +USER node +EXPOSE 3000 +ENTRYPOINT ["flowise", "start"] +``` + +`--legacy-peer-deps` evita instalar integraciones de pares opcionales, incluida una antigua dependencia nativa de SQLite. Esta receta está orientada a PostgreSQL y flujos basados en API; instala y prueba las dependencias adicionales por separado para los nodos que las necesiten. + +Selecciona el Dockerfile explícitamente: + +```bash +lizard service set flowise --set dockerfilePath=Dockerfile +``` + + + +## Configurar PostgreSQL y el cifrado + +Haz referencia a las variables de la base de datos en el servicio de Flowise: + +```bash +lizard secrets set \ + DATABASE_TYPE=postgres \ + DATABASE_HOST='${{flowise-db.PGHOST}}' \ + DATABASE_PORT='${{flowise-db.PGPORT}}' \ + DATABASE_USER='${{flowise-db.PGUSER}}' \ + DATABASE_PASSWORD='${{flowise-db.PGPASSWORD}}' \ + DATABASE_NAME='${{flowise-db.PGDATABASE}}' \ + --service flowise +``` + +Mantén las comillas simples para que tu shell no expanda las referencias. Lizard las resuelve cuando el servicio se inicia. + +Genera los siguientes secretos una sola vez durante la configuración: + +```bash +lizard secrets set \ + FLOWISE_SECRETKEY_OVERWRITE="$(openssl rand -hex 32)" \ + JWT_AUTH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + JWT_REFRESH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + EXPRESS_SESSION_SECRET="$(openssl rand -hex 32)" \ + TOKEN_HASH_SECRET="$(openssl rand -hex 32)" \ + SECURE_COOKIES=true \ + --service flowise +``` + +Guarda una copia segura de estos valores. En particular, conserva `FLOWISE_SECRETKEY_OVERWRITE`: Flowise necesita la misma clave para descifrar las credenciales ya almacenadas en PostgreSQL. No regeneres los secretos al reiniciar, volver a implementar o actualizar. + + + +## Implementar y crear tu cuenta + +```bash +lizard up --service flowise --port 3000 +``` + +La primera compilación instala Flowise y sus dependencias, por lo que puede tardar varios minutos. Abre la URL HTTPS que devuelve la implementación y crea la primera cuenta de propietario antes de compartir la URL. Inicia sesión en el editor. + +Establece la URL pública para los enlaces que genera Flowise, reemplazando el ejemplo por tu URL HTTPS real: + +```bash +lizard secrets set APP_URL=https://YOUR-SERVICE.onlizard.com --service flowise +``` + +Este cambio reinicia el servicio. Configura SMTP por separado si necesitas correos de restablecimiento de contraseña o invitaciones. + + + +## Verificar la persistencia + +Crea y guarda un flujo. Añade una credencial de prueba y luego reinicia Flowise: + +```bash +lizard restart --service flowise +``` + +Espera hasta que el servicio esté en ejecución, vuelve a iniciar sesión y comprueba que el flujo y la credencial siguen ahí. Ejecuta un flujo que use la credencial para confirmar que Flowise todavía puede descifrarla. Repite la comprobación después de volver a implementar: + +```bash +lizard redeploy --service flowise +``` + +Haz una copia de seguridad tanto de PostgreSQL como de la clave de cifrado. Una copia de seguridad de la base de datos sin la clave no puede recuperar las credenciales guardadas. + + + +## Almacenamiento de archivos + +PostgreSQL no almacena todos los archivos que escribe Flowise. Esta configuración no monta un volumen de archivos persistente, así que las subidas locales, las bases de datos vectoriales locales y los registros de archivos pueden desaparecer cuando se reemplaza el contenedor. + +Antes de usar subidas o flujos de trabajo con documentos, configura un bucket S3 privado usando las [variables de almacenamiento](https://docs.flowiseai.com/configuration/environment-variables) de Flowise. Establece `STORAGE_TYPE=s3`, `S3_STORAGE_BUCKET_NAME`, `S3_STORAGE_ACCESS_KEY_ID`, `S3_STORAGE_SECRET_ACCESS_KEY` y `S3_STORAGE_REGION`. Para un proveedor compatible con S3, establece también `S3_ENDPOINT_URL` y `S3_FORCE_PATH_STYLE=true`. + +Managed Object Storage de Lizard crea un bucket `default` de lectura pública. No coloques documentos privados de Flowise en ese bucket sin antes cambiar su configuración de acceso. La configuración de PostgreSQL anterior no aprovisiona ni prueba almacenamiento de archivos, almacenes vectoriales locales ni workers de cola. + + + +## Solución de problemas y actualizaciones + +```bash +lizard events --service flowise +lizard logs --build --service flowise +lizard logs --service flowise +``` + +Si una primera implementación agota el tiempo mientras la imagen todavía se está descargando, inspecciona `lizard events`. Una vez que el contenedor haya arrancado, vuelve a intentar `lizard up --service flowise --port 3000`. Un servicio sin ninguna compilación previa correcta todavía no puede usar `lizard redeploy`. + +Para las actualizaciones, haz una copia de seguridad de la base de datos, lee las notas de versión de Flowise, cambia la versión de npm en el Dockerfile y súbelo de nuevo con `lizard up`. Verifica la nueva versión y ejecuta las comprobaciones de persistencia antes de depender de la actualización. diff --git a/_locales/es/guides/index.mdx b/_locales/es/guides/index.mdx new file mode 100644 index 0000000..623da7b --- /dev/null +++ b/_locales/es/guides/index.mdx @@ -0,0 +1,25 @@ +--- +description: "Guías de tareas para desplegar desde agentes de programación, alojar servidores MCP remotos, ejecutar workers de Telegram y conservar archivos de sandbox." +--- + + + +# Guías + +Elige la carga de trabajo que quieres ejecutar. Cada guía explica su configuración, comprobaciones y límites; usa la referencia de comandos cuando necesites la sintaxis exacta de una opción. + +| Tarea | Guía | +|---|---| +| Desplegar una app escrita por Claude Code, Codex o Cursor | [Desplegar desde un agente de programación](/guides/deploy-from-coding-agent) | +| Dar a un cliente MCP un endpoint HTTPS remoto | [Alojar un servidor MCP remoto](/guides/deploy-mcp-server) | +| Mantener un proceso de long polling de Telegram en ejecución | [Ejecutar un bot de Telegram](/guides/telegram-bot) | +| Consumir trabajos en cola sin un listener HTTP | [Workers en segundo plano](/deploy/workers) | +| Ejecutar código en un guest Linux independiente | [Inicio rápido de Sandboxes](/sandboxes/quickstart) | +| Recopilar analíticas de sitios web con PostgreSQL | [Ejecutar Umami](/guides/umami) | +| Mantener los flujos de Flowise y las credenciales cifradas en PostgreSQL | [Ejecutar Flowise](/guides/flowise) | +| Reutilizar archivos en un sandbox posterior | [Persistent Volumes](/sandboxes/volumes) | + +Consulta los [límites](/platform/limits), el [almacenamiento y la recuperación](/platform/storage-and-recovery) y los [problemas conocidos](/platform/known-issues) al elegir un recurso. + +Lee los [resultados de las pruebas de escenarios](/guides/validation) para ver las versiones probadas, las comprobaciones en la nube y las brechas restantes. + diff --git a/_locales/es/guides/telegram-bot.mdx b/_locales/es/guides/telegram-bot.mdx new file mode 100644 index 0000000..11e9bb6 --- /dev/null +++ b/_locales/es/guides/telegram-bot.mdx @@ -0,0 +1,101 @@ +--- +description: "Ejecuta un bot de Telegram con long polling como un worker de Lizard. Configura su token, desactiva el enrutamiento HTTP, mantén una réplica y revisa los mensajes y reintentos." +--- + + + +# Ejecutar un bot de Telegram + +Un bot con long polling es un worker en segundo plano: solicita actualizaciones a Telegram y no necesita un endpoint HTTP público. Ejecútalo con `containerPort=0` y una réplica por token de bot. + +**Estado de las pruebas:** pasan siete pruebas locales con respuestas de Telegram simuladas. No hemos comprobado esta guía con un bot real en la nube. Usa un bot de prueba independiente y completa las comprobaciones de mensajes y reinicios que aparecen abajo antes de confiar en él. Consulta los [resultados de las pruebas de escenario](/guides/validation). + + + +## Antes de empezar + +Crea un bot con BotFather y mantén su token en privado. Necesitas Python 3.13, Lizard CLI y un proyecto que puedas desplegar. Un bot que usa long polling no debe tener un webhook activo; revisa su configuración actual antes de cambiar la forma en que recibe actualizaciones. + +Los [archivos de ejemplo](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/telegram-worker) incluyen `worker.py`, un Dockerfile y pruebas unitarias locales. Las pruebas no llaman a Telegram. El controlador de eco guarda su offset en memoria; no es un sistema de procesamiento exactamente una vez. + + + +## Comprobar localmente + +Desde el directorio del ejemplo: + +```bash +python3 -m unittest -v +``` + +Las comprobaciones cubren respuestas de texto, actualizaciones ignoradas, sondeos vacíos y envíos fallidos. Ejecuta el bot localmente con `TELEGRAM_BOT_TOKEN` configurado solo si tienes intención de enviar respuestas. Detén ese proceso local antes de iniciar el worker alojado. + + + +## Desplegar como worker + +```bash +lizard init --name telegram-bot +lizard add --service bot +``` + +Inicia sesión con `lizard login` si un comando informa que se requiere autenticación. Configura `TELEGRAM_BOT_TOKEN` en el **servicio del bot** antes de desplegar. Puedes usar el editor de variables del panel o poner el valor en un archivo local `.env` e importarlo: + +```bash +lizard secrets import --service bot < .env +lizard run --service bot -- python3 check_bot.py +lizard up --service bot --port 0 +``` + +La comprobación previa valida el token con `getMe` y rechaza un bot con un webhook activo. No elimina ni cambia ese webhook. Un segundo proceso de polling aún puede entrar en conflicto: detén cualquier copia local antes del despliegue. + +El ejemplo excluye `.env*` de las cargas. Mantén el token fuera de los archivos fuente y las capturas de pantalla. En macOS con Lizard CLI 0.3.92, añade el prefijo `COPYFILE_DISABLE=1` al comando de carga. Lee el evento final del despliegue y los logs incluso si el comando termina correctamente. + +Para un servicio existente, configura explícitamente el modo worker: + +```bash +lizard service set bot --set containerPort=0 +``` + +Después de cambiar el modo worker en un servicio en ejecución, aplícalo con `lizard redeploy --service bot`. Revisa los eventos del despliegue antes de solicitar otra compilación. El modo worker omite las comprobaciones de puerto HTTP y la ruta del balanceador de carga; no añadas un servidor web ficticio solo para que este proceso parezca una aplicación HTTP. + + + +## Verificar el resultado + +```bash +lizard ps --json +lizard logs --service bot --json +lizard events --json +``` + +El log debe mostrar `Telegram worker started`. Envía un mensaje a tu bot y comprueba que haya una única respuesta de eco. Luego detén y reinicia el worker durante una ventana de pruebas aprobada y confirma que se vuelve a conectar. Un worker marcado como en ejecución igualmente necesita esta comprobación a nivel de aplicación. + + + +## Fallos comunes + +| Síntoma | Comprobación | +|---|---| +| El proceso termina inmediatamente | Configura `TELEGRAM_BOT_TOKEN` en el servicio que lo consume. | +| La comprobación de estado HTTP nunca se aprueba | El modo worker debe usar `containerPort=0`. | +| Las actualizaciones se detienen o aparecen errores de conflicto | Solo un proceso de polling debe usar este token; comprueba si hay un proceso local, otra réplica o un webhook activo. | +| Respuestas repetidas después de un fallo | La demo no persiste offsets ni elimina duplicados de IDs de actualizaciones. Añade idempotencia duradera antes de manejar acciones irreversibles. | +| Reintentos frecuentes | Comprueba el acceso de red, la validez del token, los límites de Telegram y tu controlador. No imprimas las URL de solicitud: contienen el token. | + + + +## Estado y costo + +Para un estado duradero del bot, conecta [Managed Postgres](/addons/postgres). Guarda los IDs de actualizaciones procesadas y haz que los controladores sean seguros para reintentar. El long polling puede mantener activo el worker entre mensajes; calcula el presupuesto a partir de [pricing](https://lizard.build/pricing) y del uso observado de recursos, no solo del número de mensajes. + + + +## Guías relacionadas + +- [Workers en segundo plano](/deploy/workers) +- [Logs](/observability/logs) +- [Límites](/platform/limits) +- [Referencia de Telegram getUpdates](https://core.telegram.org/bots/api#getupdates) + +Consulta los [resultados de las pruebas de escenario](/guides/validation) para ver las versiones comprobadas, los resultados en la nube y las limitaciones restantes. diff --git a/_locales/es/guides/umami.mdx b/_locales/es/guides/umami.mdx new file mode 100644 index 0000000..504dde9 --- /dev/null +++ b/_locales/es/guides/umami.mdx @@ -0,0 +1,122 @@ +--- +description: "Implementa Umami con Managed Postgres, configura sus secretos de cifrado y revisa las analíticas después de un reinicio y una nueva implementación." +--- + + + +# Ejecutar Umami + +Esta guía ejecuta la imagen oficial de Docker de Umami en Lizard con una base de datos PostgreSQL independiente. Usa Lizard CLI para implementar un Dockerfile local pequeño y exponer Umami por HTTPS. + + + +## Requisitos previos + +- Una cuenta de Lizard con acceso al alojamiento de aplicaciones y Managed Postgres. +- Node.js y npm en tu equipo, además de OpenSSL para generar secretos. + +Instala Lizard CLI e inicia sesión: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +Completa el inicio de sesión en tu navegador antes de continuar. Los comandos siguientes se probaron con Lizard CLI 0.3.95 y Umami 3.3.1. + + + +## Crear el proyecto y la base de datos + +Usa un directorio nuevo para esta implementación: + +```bash +mkdir umami-on-lizard +cd umami-on-lizard +lizard init --name umami-on-lizard +lizard add postgres --name umami-db +lizard add --service umami +``` + +Si perteneces a más de un workspace, pasa `--workspace ` a `lizard init` para elegir uno. Espera a que la base de datos llegue a `running` antes de implementar Umami. + + + +## Configurar la imagen y los secretos + +Crea un archivo llamado `Dockerfile`: + +```dockerfile +FROM ghcr.io/umami-software/umami:3.3.1 +EXPOSE 3000 +``` + +Indica a Lizard que use este archivo tal como está escrito: + +```bash +lizard service set umami --set dockerfilePath=Dockerfile +``` + +Conecta la base de datos y genera dos secretos independientes: + +```bash +lizard secrets set \ + DATABASE_URL='${{umami-db.DATABASE_URL}}' \ + APP_SECRET="$(openssl rand -hex 32)" \ + TWO_FACTOR_ENCRYPTION_KEY="$(openssl rand -hex 32)" \ + --service umami +``` + +Mantén las comillas simples alrededor de la referencia de la base de datos: Lizard la resuelve cuando se inicia el servicio. Los valores pertenecen a este servicio, por lo que otras aplicaciones del proyecto no los reciben. + +Guarda ambos secretos generados en tu gestor de contraseñas. Configúralos una sola vez durante la instalación; no los regeneres al reiniciar o actualizar. `TWO_FACTOR_ENCRYPTION_KEY` es obligatorio para la autenticación de dos factores. + + + +## Implementar e iniciar sesión + +Desde el directorio que contiene el Dockerfile, ejecuta: + +```bash +lizard up --service umami --port 3000 +``` + +La imagen de Umami ejecuta la configuración de su base de datos y las migraciones al iniciarse. No se necesita un comando de migración independiente para esta imagen. + +Abre la URL HTTPS que devuelve la implementación. Para una base de datos nueva de Umami 3.3.1, inicia sesión con el nombre de usuario `admin` y la contraseña `umami`, y luego cambia inmediatamente la contraseña en tu perfil antes de compartir la URL. Añade un sitio web e instala su script de seguimiento en una página que controles. + +Si la implementación falla, revisa su estado y sus registros: + +```bash +lizard events --service umami +lizard logs --build --service umami +lizard logs --service umami +``` + +Si el primer inicio supera el tiempo de espera, revisa `lizard events` para comprobar si el contenedor está listo. Una vez que el contenedor se haya iniciado, vuelve a intentar la carga con `lizard up --service umami --port 3000`. + + + +## Comprobar la persistencia de los datos + +Visita la página rastreada y confirma que Umami registra una vista de página. Reinicia la aplicación: + +```bash +lizard restart --service umami +``` + +Espera a que el servicio vuelva a ejecutarse. Confirma que tu nueva contraseña funciona y que el sitio web y la vista de página se mantienen. Luego repite la comprobación después de una nueva implementación: + +```bash +lizard redeploy --service umami +``` + +Umami almacena las cuentas, la configuración del sitio web y las analíticas en PostgreSQL. La aplicación no necesita un volumen de archivos para esos registros. Conserva la base de datos y los secretos de cifrado al reemplazar o actualizar la aplicación. Una comprobación tras reiniciar no sustituye un plan probado de copia de seguridad y restauración de la base de datos. + + + +## Actualizar Umami + +Haz una copia de seguridad de PostgreSQL y lee las notas de la versión antes de actualizar. Cambia la etiqueta de la imagen en el Dockerfile local y luego ejecuta `lizard up --service umami --port 3000` de nuevo. Para esta configuración basada en cargas, `lizard redeploy` recompila los últimos archivos cargados; no carga las ediciones locales. + +Consulta la [guía de PostgreSQL de Lizard](https://lizard.build/docs/addons/postgres/) para el acceso a la base de datos y [almacenamiento y recuperación](https://lizard.build/docs/platform/storage-and-recovery/) para la planificación de copias de seguridad. diff --git a/_locales/es/guides/validation.mdx b/_locales/es/guides/validation.mdx new file mode 100644 index 0000000..d5570d6 --- /dev/null +++ b/_locales/es/guides/validation.mdx @@ -0,0 +1,39 @@ +--- +description: "Verifica las guías de MCP, coding-agent, worker de Redis y Telegram: resultados en la nube, comportamiento al reiniciar, versiones probadas y límites restantes." +--- + + + +# Resultados de pruebas de guías de escenarios + +El 2026-09-07, verificamos estas guías en un proyecto de prueba separado con Lizard CLI 0.3.92. Las verificaciones de la aplicación son independientes del estado de compilación. Las pruebas usaron los comandos de la guía, con un nombre de proyecto distinto y la rama de prueba de documentación para el ejemplo de GitHub. + +| Guía | Resultado | Comprobaciones | +|---|---|---| +| [Remote MCP](/guides/deploy-mcp-server) | Aprobado localmente y en la nube | Health 200; token faltante e inválido 401; GET autenticado 405; Origin rechazado 403; initialize, tools/list y tools/call; resultado `5` sobre HTTPS público | +| [Agente de codificación: subida](/guides/deploy-from-coding-agent) | Aprobado | `lizard up`, health 200, respuesta con respaldo en base de datos 200, ruta desconocida 404; una fila de Postgres actualizada permaneció después de reiniciar el servicio | +| [Agente de codificación: GitHub](/guides/deploy-from-coding-agent) | Aprobado | Repositorio adjunto con `--no-deploy`; rama, directorio raíz y entorno configurados antes de `redeploy`; la aplicación pública leyó la misma fila existente de Postgres | +| [Redis worker](/deploy/workers) | Aprobado | Puerto 0; enqueue y resultado; resultado conservado después del reinicio; nuevo trabajo después del reinicio; una entrada de procesamiento sin finalizar se recuperó al iniciar | +| [Telegram bot](/guides/telegram-bot) | Solo pruebas locales | Siete pruebas simuladas cubren updates, envíos fallidos, verificaciones de token y rechazo de webhook. Todavía se requiere un token real, chat y prueba de eco en la nube | + + + +## Versiones + +El contenedor de MCP ejecutó Node.js 22.23.2 con MCP TypeScript SDK 1.30.0. El ejemplo de coding-agent usa `pg` 8.16.3 y se conectó a Managed Postgres con PostgreSQL 18.4. El contenedor del worker ejecutó Python 3.13.15 con redis-py 6.4.0. Los lockfiles de dependencias o los requisitos exactos están en los ejemplos. + + + +## Alcance + +La verificación de MCP cubre el transporte HTTP sin estado del ejemplo y el token bearer fijo. No establece compatibilidad con OAuth, soporte de navegador, streaming de larga duración ni capacidad bajo carga. El token expira después de una hora. + +La verificación de GitHub usó la rama de documentación y el directorio `_examples/agent-app`. Probó un redeploy explícito; no probó todas las configuraciones de permisos de repositorios privados ni todos los eventos de webhook. + +La verificación de recuperación de Redis sembró una entrada de procesamiento sin finalizar antes de reiniciar un único consumidor. No probó fallos de Redis, múltiples workers ni efectos externos exactamente una vez. La verificación de base de datos establece persistencia tras reiniciar una aplicación, no copia de seguridad ni recuperación ante desastres. + +Las colas finales de logs del runtime estuvieron inicialmente vacías para los servicios de prueba. Más tarde, un stream de logs en vivo del worker mostró un trabajo recién procesado. Usa las verificaciones de HTTP, cliente MCP y resultado del trabajo como criterios de finalización; una cola de logs vacía por sí sola no establece ni éxito ni fallo. + +El ejemplo de Telegram no está marcado como verificado en la nube. Su preflight lee `getMe` y `getWebhookInfo` sin cambiar el webhook del bot. Usa un bot de prueba separado antes de habilitar su bucle de polling. + +Consulta [resultados de pruebas de frameworks](/framework-guides/validation) para el lote separado de 16 recetas de framework, y [known issues](/platform/known-issues) para los límites del archivo del CLI y los códigos de salida de compilaciones fallidas. diff --git a/_locales/es/index.mdx b/_locales/es/index.mdx new file mode 100644 index 0000000..f09790d --- /dev/null +++ b/_locales/es/index.mdx @@ -0,0 +1,57 @@ +--- +description: "Despliega una app, ejecuta un worker, conecta Managed Postgres o ejecuta código en Sandboxes. Elige una tarea, sigue una guía y revisa los límites." +--- + + + +# Documentación de Lizard + +Lizard compila y ejecuta aplicaciones desde un repositorio de GitHub o una carpeta local. Usa Lizard CLI o el panel para desplegar un servicio web, ejecutar un worker en segundo plano, conectar Managed Postgres o Managed Redis, e inspeccionar logs. Usa Lizard SDK para crear Sandboxes para la ejecución de código. + + + +## Elige una tarea + +| Quiero… | Empieza aquí | +|---|---| +| Desplegar mi primera app | [Guía rápida de apps](/getting-started) | +| Desplegar Next.js, React, Vue o una app de Python | [Guías de frameworks](/framework-guides) | +| Desplegar desde Claude Code u otro agente de programación | [Guía de agentes de programación](/guides/deploy-from-coding-agent) | +| Alojar un servidor MCP remoto | [Guía de MCP remoto](/guides/deploy-mcp-server) | +| Mantener un bot de Telegram en ejecución | [Guía de workers de Telegram](/guides/telegram-bot) | +| Conectar una base de datos | [Managed Postgres](/addons/postgres) | +| Ejecutar código generado en un entorno separado | [Guía rápida de Sandboxes](/sandboxes/quickstart) | +| Conservar archivos después de que termine un sandbox | [Persistent Volumes](/sandboxes/volumes) | + + + +## Despliega una app + +Instala Lizard CLI e inicia sesión; luego despliega un repositorio al que tengas acceso: + +```bash +npm install -g @lizard-build/cli +lizard login +lizard add -r your-org/your-app +``` + +Lizard compila la imagen en sus servidores, así que esta ruta no necesita Docker local. [lizardpack](/concepts/build-pipeline) detecta los proyectos compatibles; los proyectos con necesidades de compilación especiales pueden usar comandos explícitos o un Dockerfile. Revisa los logs de compilación y verifica la URL de la aplicación después del despliegue. + + + +## Entiende tus recursos + +Un **workspace** agrupa miembros y proyectos. Un **project** agrupa servicios, bases de datos y Sandboxes. Un **service** ejecuta una aplicación o un worker. Managed Postgres, Managed Redis y Managed Object Storage proporcionan servicios de datos a los que las aplicaciones se conectan mediante referencias de entorno. + +Las apps y Sandboxes tienen reglas distintas de ejecución y almacenamiento. Lee [límites](/platform/limits) y [almacenamiento y recuperación](/platform/storage-and-recovery) antes de depender del tamaño, la duración o la retención de datos de un recurso. + + + +## Encuentra el nivel de detalle adecuado + +- [Guías](/guides) cubren una tarea desde la configuración hasta la comprobación del resultado. +- [Guías de frameworks](/framework-guides) ofrecen comandos de compilación, adaptadores, puertos y comprobaciones para cada stack. +- [Conceptos básicos](/concepts/architecture) explican proyectos, compilaciones y despliegues. +- [Referencia de Lizard CLI](/cli) enumera comandos, flags y códigos de salida. +- [Solución de problemas](/deploy/troubleshooting/service-never-healthy) ayuda a diagnosticar un inicio fallido. +- [Problemas conocidos](/platform/known-issues) registra límites y casos de recuperación que conviene revisar antes de una versión. diff --git a/_locales/es/manifest.json b/_locales/es/manifest.json new file mode 100644 index 0000000..b3fc467 --- /dev/null +++ b/_locales/es/manifest.json @@ -0,0 +1,576 @@ +{ + "locale": "es", + "status": "published", + "pages": [ + { + "path": "addons/index.mdx", + "sourceSha256": "a364ec2783f0102fb3067cc844c4db4e6709b3bc522508dea3ccc67aae830ae0", + "translationSha256": "304ed5d75fe76e9eabbfe19cb4fa2e6da7c497377eb595a6022edba7008db9a6", + "status": "published" + }, + { + "path": "addons/postgres.mdx", + "sourceSha256": "78346399743959929c09c87d1d98a7e8274d93c1e21a764df94a02b613ac0d09", + "translationSha256": "ca1fff3dcb35e389cbd626790d2bf8a0bde9bcfea0aa3757d8a29dae1b217ab2", + "status": "published" + }, + { + "path": "addons/redis.mdx", + "sourceSha256": "5c295a88f06837b2c581b62b2a8787dec1f8da73c77cdf1c8a8b051d5fdd9c19", + "translationSha256": "6569c20d91beb7ea38ca10e89e71ff1775ed14786704416341b03aec85121c5a", + "status": "published" + }, + { + "path": "addons/storage.mdx", + "sourceSha256": "60eb80b5a079fc37daa87d064bbb6824ff8061682f54671567389b41ea9a2e3a", + "translationSha256": "9976c973cd2832ffb7a97b05aab84ccfcdf2b4bc3be493862d8ec70180b74d46", + "status": "published" + }, + { + "path": "agents.mdx", + "sourceSha256": "6d12cad052e608f5685ce8a08051d0b5c9d0f0981c06ddf7aa422479f8a6a20a", + "translationSha256": "425cb47591e1e4803b345c7610ee53cbb4c00c752f031299606076722a93be91", + "status": "published" + }, + { + "path": "cli/add.mdx", + "sourceSha256": "da07da89b28ff85a02dd9afd621d75c935a8e47e26c3bb1bebdeb4fae7d935b7", + "translationSha256": "fb9e4ccd93d4c0064097d9a3a16cd646586fdda922e362798faffb6d493edb9c", + "status": "published" + }, + { + "path": "cli/config.mdx", + "sourceSha256": "7ff4c3a6d511e1bf7086f6ea11f47af473c9fd6d15865808bdd0548c265bcd56", + "translationSha256": "eb292ae7f6b0ed39f25d9fd5befaf37a96c7c1ec77db2e83ea7054dc40c99441", + "status": "published" + }, + { + "path": "cli/docs.mdx", + "sourceSha256": "2f99ebda3a4339d975e1b12c6e8949b4aac33e2b6b4284cfbf5944b274936b83", + "translationSha256": "3220d2f776bd8eea623d0045e7f5cd8592d7a206c821c863476e8b25d89e6db8", + "status": "published" + }, + { + "path": "cli/domain.mdx", + "sourceSha256": "9d4d1e70a6b4078de6486abf9f3f8c679b922e117823232d41df0e403918458f", + "translationSha256": "f50a783eef015fd73bec5d4785a8f1f3221794c717512fb87d8d27219f138f9c", + "status": "published" + }, + { + "path": "cli/events.mdx", + "sourceSha256": "ce890a024e8b37c7566a3f23d74fe867554aacbcf034103a64d48ba910b4aa4d", + "translationSha256": "49430e367741c4a0a162dd460681ab519ffc2fbb2e75907584e352d1cd3ecc12", + "status": "published" + }, + { + "path": "cli/git.mdx", + "sourceSha256": "d41bde854400c6879516d11f06a0792adad0491f294addcb6a3fbbaca140d2f5", + "translationSha256": "9dd368e5676c396dd72a17e918224d1bdefd39ee024b91131ae3afaf89050c90", + "status": "published" + }, + { + "path": "cli/index.mdx", + "sourceSha256": "b9f5bb24b661770d8b5fe2916ea43890af08cafc17f32ccd0e49d2e56a0df422", + "translationSha256": "d145c2c480a057471d99155b09c97a7087075d9fc17a4e73cecd2d1c48d4791b", + "status": "published" + }, + { + "path": "cli/init.mdx", + "sourceSha256": "9ea4e3b5641acc86a3bb0e7013f74cd03df18d64a150858f33cc4220e987cfc7", + "translationSha256": "913659cefc9f601c8536e311bb12865bda824d44af6a0e1582eb35e03d88c44c", + "status": "published" + }, + { + "path": "cli/json.mdx", + "sourceSha256": "0db2f5c74b3d7d55b467f5235d38805f5ba531b3b56b60eeb591722b89634798", + "translationSha256": "886d4d67595f05b7ed00197c8d81ba0bcfbb5fd17b24dd231bc95dbdb9109297", + "status": "published" + }, + { + "path": "cli/link.mdx", + "sourceSha256": "c830b5269697edcce4a1344de712a26319d60dbb73f9aee71f905da45f301c90", + "translationSha256": "870220f67e2e04cea53c1844da3f39d36b26d33e508909b9cfc2a9911bf2811d", + "status": "published" + }, + { + "path": "cli/login.mdx", + "sourceSha256": "732fd0d32942e45da0f61325478ac2853710161f8d8dd9cbd874b192ddd41220", + "translationSha256": "8526c1b0915e536c70f5ffc955697841f8fd06cc1f311c46cacc56553d03e957", + "status": "published" + }, + { + "path": "cli/logout.mdx", + "sourceSha256": "a8e49ead7c934a4c29d44421349bd46d3f7f1cc81dbde03ef4350d10cbf12e03", + "translationSha256": "3058b2b3b7c55a2f67ce229276634270f3f7ac5d9fa5e333f104798d506e374d", + "status": "published" + }, + { + "path": "cli/logs.mdx", + "sourceSha256": "deebb5f030fb9b3a36000036f9b8f829fc8319cd0c559ebe0f528f175d5eb384", + "translationSha256": "32a31a0390393f2f35902d600764f13f48b57169d57db88fd53ad3156bf3ef55", + "status": "published" + }, + { + "path": "cli/metrics.mdx", + "sourceSha256": "dcfa3c003c126ccbc276d2423d5d8fab30adfb685459c4cf546cc53ed02d3429", + "translationSha256": "2072b009b2ab712442c090401c52f58447e4e7a03322df92bfd64007a577f549", + "status": "published" + }, + { + "path": "cli/open.mdx", + "sourceSha256": "34659aaba345efeca309eded62ca791414e7f2cac10aa6a66b1fc81a6adcc7cd", + "translationSha256": "215caaf0f2a7416a30ff5ff879e11ba45d13e1e53dc2bcfc295c997b4ad5fed8", + "status": "published" + }, + { + "path": "cli/port.mdx", + "sourceSha256": "925f588fe174b968738163a0c064af2090b9d4489dd82a75a5b111d8c002f8e8", + "translationSha256": "36eda670f2ee5b5ee31af9a46394a9c1a9904e587f6e01daa9eca57153152d2f", + "status": "published" + }, + { + "path": "cli/project.mdx", + "sourceSha256": "3cd89738f9965ece2a6ec8158963cfe3d0f118bf81334dde58792ac858890521", + "translationSha256": "0f011d4180ba96003b96f5c1a3695acc606685ff3abed05326f22b10d87a4c35", + "status": "published" + }, + { + "path": "cli/ps.mdx", + "sourceSha256": "7cae9f4efdd03bd9cc38affa13ce3537d8f6a6cb8ec4a3e12748235a29afb7d1", + "translationSha256": "a3ef3904747fdc3895ad3a14b7fbb10d56f3761e952ca350c99b9e056f20d95f", + "status": "published" + }, + { + "path": "cli/redeploy.mdx", + "sourceSha256": "69e3567d19d1eee5ecb88848519c871170982cd8bdae0cc832848425c00976f4", + "translationSha256": "671f63c60e4f284b0dffc707ecb9cb148836a75645934cb829662dbb86dee7e3", + "status": "published" + }, + { + "path": "cli/regions.mdx", + "sourceSha256": "fb4374ff44f0cb307cda3b11a32d2af140628aecefcc72648c8bd4fac79a0390", + "translationSha256": "ae195f2c08db4f611e55354a46761fd3e9157df3db4346552856dae04a6b08df", + "status": "published" + }, + { + "path": "cli/restart.mdx", + "sourceSha256": "0001cc039c216e29704bc8dd032843f33eeda479e3b936864c55ebb82c19392b", + "translationSha256": "0449254c9b11d5c635c7450a11e30fe21a30992c9c9914afbcd42d3471104aa0", + "status": "published" + }, + { + "path": "cli/run.mdx", + "sourceSha256": "3edbc8067d4e4223e7f8fabab0d031173b096b641134895988c9693bdc10b5d6", + "translationSha256": "9a6b090857c4e003b46b448d5048103da5577b204d3cb168c7733c0ea056fde3", + "status": "published" + }, + { + "path": "cli/scale.mdx", + "sourceSha256": "d0128acc8893d2b40bc7b663fe48867ed247851cddc52817ef2f1a55a97bef5e", + "translationSha256": "1ec8cc976c674464f68a935c6eca508bfadfe73a3b7589841714b041b14c35e6", + "status": "published" + }, + { + "path": "cli/secrets.mdx", + "sourceSha256": "635491af6079e6a4f8c718f5443f5b19b9b3e8697957a2917a451631eecf3282", + "translationSha256": "6eaf5fcd90bbd930faf6d92e709bb9bea7350a9c0375ccab87e60580a77132d9", + "status": "published" + }, + { + "path": "cli/service.mdx", + "sourceSha256": "f4a4dedae24ae7928cc0e8279525f80551f1bb01b209beb97254b5966d8ff038", + "translationSha256": "af5a65d24f5474af91966658bfcc44aaf69d06b07b7fea108a3de324891ecbcc", + "status": "published" + }, + { + "path": "cli/skills.mdx", + "sourceSha256": "5ee058f81c64343d5667de9ebd49f1bc975010a25258a74ce92458d638b7731b", + "translationSha256": "c4dc862935eb027f505d12ce3942083b90cb986989343b0803cd782783427c5d", + "status": "published" + }, + { + "path": "cli/ssh.mdx", + "sourceSha256": "f2c1105cca6be5eff87de0249a23d52dd4b5302065b6a0839ba3106669664e46", + "translationSha256": "bedbb12b6e7b1c00170cd2776d48caf37647393528216baa7c710456688fe2e6", + "status": "published" + }, + { + "path": "cli/status.mdx", + "sourceSha256": "d1c2b6873e7679bdb11253c71aa03566f64c9d46f30a9de283ac58b42a47af8a", + "translationSha256": "36cc86c6a7535fb140fe1db73b53f5d69061fb71c922537b654eddfa7a0681a3", + "status": "published" + }, + { + "path": "cli/unlink.mdx", + "sourceSha256": "e824c1f057db0696eee4b37488cdd43292dbe9d08770112d3e9af9b9ab70a5d6", + "translationSha256": "0bb450140738b90b25eb6a61841874a4cf11a7e322465da7aec591a16ca16835", + "status": "published" + }, + { + "path": "cli/up.mdx", + "sourceSha256": "8d7512c5e26dbf5a0316437f99e1cc93ce0ebdfe7bf69491636ed767eda36695", + "translationSha256": "3330df4ef653e21e897c92462013e1d2f6a4a285977bf27489cfc10629a91e4b", + "status": "published" + }, + { + "path": "cli/upgrade.mdx", + "sourceSha256": "1f33d0a46185278e2858d89f7a19e9e57a63d5dd6bd36c66c0f4f348384c8e93", + "translationSha256": "2e7b51e20c4065d371013c793f85d24c80981bdd6983691366edbaaf365f0d26", + "status": "published" + }, + { + "path": "cli/whoami.mdx", + "sourceSha256": "053bc71c8bd276882bdd10cd64d42ce8e13e500c01424fcfd8e1fd7083b3467d", + "translationSha256": "d22b10057279be537ef98ef39394cb7515b7534fad5d3e90a67887c1ead4aff4", + "status": "published" + }, + { + "path": "cli/workspace.mdx", + "sourceSha256": "bc138c7663e0b4c8ae76c3b2d55c9f72d83fa08fc19f3475d5e7bc08e7da78d2", + "translationSha256": "5552d38ee2b0b9efeae9fc1b9c5faf0152e59d1ba180924e03b66e95e7819ceb", + "status": "published" + }, + { + "path": "concepts/architecture.mdx", + "sourceSha256": "fa5a5aa8a4f23b1d89be99fd3d8db0a9f19831991f9d5fb55730fd12dd399cff", + "translationSha256": "6852f7fc514367d16313da8433afa71c06ee9fc55ca8bc8456ef42ca3a4281df", + "status": "published" + }, + { + "path": "concepts/build-pipeline.mdx", + "sourceSha256": "b0ec0991712b3f5ef246a1ec3dea10687a7c592debecec517b6498db2daa4bb3", + "translationSha256": "4b4a035998c01f59b4998ed33923209c1c1f1a05bef1401b18f025aeadc58598", + "status": "published" + }, + { + "path": "concepts/deployments.mdx", + "sourceSha256": "0f54a580f17b7c807cadebe8b0d6ef9bfd793e8b16486c51c6cffb40a8eb8bba", + "translationSha256": "1cbd2c30813ef3874e81d0ac343176e2fa6ce0558c1afcdc90f592ef779e24d5", + "status": "published" + }, + { + "path": "concepts/index.mdx", + "sourceSha256": "92ffb749631fb660c542e40ff875f7cd8aa4849c9d77d06f4ac286578ee58bc4", + "translationSha256": "4ca86e292a46d2093b296a905163e270c83ee76fc02929a339b1681ae8d7729c", + "status": "published" + }, + { + "path": "dashboard.mdx", + "sourceSha256": "4fa1240afec8962e3df1c9e564280c83963761f2f64b47502eb8b0d9e9d2ed0c", + "translationSha256": "99c9ae116d55a10fc9c01a432bd1ecd2a0aac7d2f8cd56dff0e11a54f10d6da3", + "status": "published" + }, + { + "path": "deploy/github.mdx", + "sourceSha256": "697a33210ef14bb34a5074f44847fa69cb7ea169494942fc571e773b200b44c2", + "translationSha256": "e63a1042d7b49afe182faf519b89b55f90dde9e67d247e6d9fe4eee26e3fd453", + "status": "published" + }, + { + "path": "deploy/index.mdx", + "sourceSha256": "39a4a222ec6cbf55b0d98393646ad7690433e651cc81e3954e85a713157c193f", + "translationSha256": "71ce8ed2f42f6c2203a3c4942fc77b05dfaf61920937116fabaa6922738560a0", + "status": "published" + }, + { + "path": "deploy/regions.mdx", + "sourceSha256": "83fc01f4cafa29b368b5bee232de3db69a7fa0c92fd74a6a16381c327005881e", + "translationSha256": "abbfe53f6a18455ac1dd176bb32a8088f6e12926e71b994a6049b2cd414cca1e", + "status": "published" + }, + { + "path": "deploy/scaling.mdx", + "sourceSha256": "563e23a94dc6dd4c634c141f4e953dfc97fcc9a2002cf54ba1030e36e3d83748", + "translationSha256": "9d20e8f75afbfb1c4d4db0fb0f54c906fce0dead612c0febaf1e3f4fae7e2c76", + "status": "published" + }, + { + "path": "deploy/troubleshooting/double-build.mdx", + "sourceSha256": "1d2254daad7f87e1fbe9e869bd6e0a2f7afbb71ef73e9964e2d2be3b7c011884", + "translationSha256": "aa2445bcbb752c8a227b223a3fda34a71e5bef29f25a3b15154db988826a4b0f", + "status": "published" + }, + { + "path": "deploy/troubleshooting/incomplete-dockerfile.mdx", + "sourceSha256": "6f9a46f14284e8c095ef4450973b21b6841073c0b8a959e233e267ff437cc6e0", + "translationSha256": "16d0d48f4f90e0dbf6094a64b448e2f4e2f7accc91f4a67370bc1aa3b3fcd0f8", + "status": "published" + }, + { + "path": "deploy/troubleshooting/service-never-healthy.mdx", + "sourceSha256": "9d348e4d46599ed785b0c8d7d906d3672c8ad834114a3d80834467af954e17a8", + "translationSha256": "028f6c98d7d1beaf2c006803828f9578072305bf779aaafba10d3926bafd769e", + "status": "published" + }, + { + "path": "deploy/upload.mdx", + "sourceSha256": "17fc2068ae350b3a6ab7349e29fc908abb1ca8087260c7ed8e0025ec5a053941", + "translationSha256": "ee8d50813f6de59caa53128a2b160b1f6b51b7748c194871976fabf505f3393b", + "status": "published" + }, + { + "path": "deploy/workers.mdx", + "sourceSha256": "43a2bbbb43fb079d035d5cf785f7e6c0536f84ed941e54bc8382a067df0b6fad", + "translationSha256": "2cd7d2d1e5349cb3973b8571675bf41656d901a91e8f2d67e69aee19f32eaa79", + "status": "published" + }, + { + "path": "framework-guides/astro.mdx", + "sourceSha256": "4b89ac3379be48f204f3b932680f0900161e7373ed2436590be3456dd07e6315", + "translationSha256": "dacd62141ed00782cb6137935174aab3ff9a30669a88f05b445f3baef0e64bc0", + "status": "published" + }, + { + "path": "framework-guides/django.mdx", + "sourceSha256": "11422a3685e71d7b95f2055799ca16c9037ebe8a279c1d9c1c891a2dade79440", + "translationSha256": "3d9e584c1c760765f8c0ceb89a9ebaa35d28b6db15cf9e2fdf3c6700a2463bb9", + "status": "published" + }, + { + "path": "framework-guides/docusaurus.mdx", + "sourceSha256": "65a0cbde6b2ba696cfb9cc99b45a0c4f7d7d82b24763d82230ede29eb48fe20f", + "translationSha256": "cb0a00388bd1bc28bb21e13e0d48a552ba3b79af0f29289849e870f67371dbac", + "status": "published" + }, + { + "path": "framework-guides/fastapi.mdx", + "sourceSha256": "9da90747b275c5d3b46aa6827ff7603ec6efb1cc4fffe48836c58d4770f904f8", + "translationSha256": "5848e33fdd1dfccb3c73bf05ff3caa9168a6ba79d689667f650b2e3e5929300f", + "status": "published" + }, + { + "path": "framework-guides/hugo.mdx", + "sourceSha256": "c552b74cc22994ab2e17d5a0c1eb4afdaf2d00f64960d9581bcf46300f6c202c", + "translationSha256": "fbe229fbe4bb68987178b2d54f068ae73c12e8c693952a151302deae737304a3", + "status": "published" + }, + { + "path": "framework-guides/index.mdx", + "sourceSha256": "ca924027746d3390d618495318c3fdde147d705193b3e04d30d71ac779c2a33a", + "translationSha256": "e03f05feb317ca5b48596ef6dba34daa096b3855386a23aeff6943c7e4f57426", + "status": "published" + }, + { + "path": "framework-guides/nextjs/index.mdx", + "sourceSha256": "a30666d082660a9a10e0f8a990b0ac1a476ad16d71c45c3e33d11e8d7f9ed926", + "translationSha256": "70d5ef71b3ae3162ecda8cb8e8298df11b8090b2f5b43beed2c7b153c3ff49eb", + "status": "published" + }, + { + "path": "framework-guides/nextjs/static-export.mdx", + "sourceSha256": "344b7b0a3c925f9e5f7df53054d3aa1525dd8e0b2c98c2e86fd990fa8309a795", + "translationSha256": "501b0e9e71f9bd2f496cc641b8ff9a2b9b7865a2b1fd9bbda1eaf78a7f4e389a", + "status": "published" + }, + { + "path": "framework-guides/nuxt.mdx", + "sourceSha256": "edfe7100de75c167475248a291fbb276ab899e4e9aba4aabb37745720b4180ee", + "translationSha256": "a8f23c25571a66d5417ee1890d423972efa11721385619903a71278288e544b3", + "status": "published" + }, + { + "path": "framework-guides/react.mdx", + "sourceSha256": "c96a03f9b274d91751231de136d1a37a2554ebcdad8ebffd5b11067c06537c34", + "translationSha256": "fc5047a9b245a7bb2993eda57adaeee9f7f4198ee6f5c60c2a6acfd5a9dd4ee2", + "status": "published" + }, + { + "path": "framework-guides/static-routing.mdx", + "sourceSha256": "277dbfc3d581d2ba332fe183807134aca7084876648a0aca7cb4b7cf227caf43", + "translationSha256": "cd21ded5970ca4bc1438d78cda07d701091dfb535a77b8962d0f64e79352e463", + "status": "published" + }, + { + "path": "framework-guides/sveltekit.mdx", + "sourceSha256": "eb98e0ae2bcc536998735b23d6d28ea658fce42e1139c78d3eb4570a54347d52", + "translationSha256": "b5ae03a92bb71424188cce20a7b93df53cba9d44a2de3ebed6a67dc7065a56e6", + "status": "published" + }, + { + "path": "framework-guides/validation.mdx", + "sourceSha256": "068375b554451b4be0aa21b2ea7d53789e61e44cd592947877cce6223240f26f", + "translationSha256": "179916e3d62e7afc2578520f63ad8c54a0a3522d9179595e5173692a8334f81e", + "status": "published" + }, + { + "path": "framework-guides/vitepress.mdx", + "sourceSha256": "5e3d98d5d3e2dcbb5af644fb500e39389e216efe772eda2933aa291384aebda4", + "translationSha256": "fd8260cfb335e56937f1a303ffb81db5d327146a09494607979973884205a924", + "status": "published" + }, + { + "path": "framework-guides/vue.mdx", + "sourceSha256": "442bd3f20789c9c6243ed364d8e4c350efebeb33a289334ee5222c9047217098", + "translationSha256": "20e18f11745348f62228f737484d9b33c4da115114133af87c739df76b95c9f8", + "status": "published" + }, + { + "path": "getting-started.mdx", + "sourceSha256": "34aa52cecefcc9a9ef34f3eb6586c8cd42de7cad388916e983aabc31c77a1527", + "translationSha256": "0b8f7652ad1106a5b01b4432fef4e6ed7e190021c11806b8e2e26a77114e1314", + "status": "published" + }, + { + "path": "guides/deploy-from-coding-agent.mdx", + "sourceSha256": "446afe16553138fce16e5ee5aba6c52f600eb9d7f3b326f8822eabbec56ea734", + "translationSha256": "f4acb0d8b62670c599d4665acb4ce16590fe9dafbf7d3921c86803d0167afbb2", + "status": "published" + }, + { + "path": "guides/deploy-mcp-server.mdx", + "sourceSha256": "55f7aea7cf3929bb84cd7ad4b67c1feb52cc707d888ec00fa2a7fe702d417738", + "translationSha256": "b6b6263bd3000440c5936625598ed70f3d0e37bb22c37ea8be9b2b1ead7857c4", + "status": "published" + }, + { + "path": "guides/flowise.mdx", + "sourceSha256": "fa697aec8657e3ea920d1c88a6095ff442064a0ab3c0a812f10e5e5c5c1ee1b6", + "translationSha256": "bddffb53de8dba93268f0a9158161ed1a629bfbf878fdc01b95a8ad1136d02cb", + "status": "published" + }, + { + "path": "guides/index.mdx", + "sourceSha256": "6492dcbd87273f0bc2148b1b3cf3e787ce4873932c2b270d11685f8984615ac6", + "translationSha256": "ffd3bb0496edd9e8cd8eb26650e761cd943a57098d2c77ba966d6c7fd6d73688", + "status": "published" + }, + { + "path": "guides/telegram-bot.mdx", + "sourceSha256": "db7b0a93dbae68b767e93022e99d2684dc7f8881bb4060cc2743c2f95742510a", + "translationSha256": "9a3f6526bae01711e9e6d8659de829f1418baedfee3b34f00fbabe6e5293158c", + "status": "published" + }, + { + "path": "guides/umami.mdx", + "sourceSha256": "60ac58aa3f74b7b22f7a29c2dabb1040983ffb9635ec0364bea5f4eeb9a1a184", + "translationSha256": "0f934aea820f4ee0b9a14de1e1b3048fb562f80829ad801df9a89354ed654790", + "status": "published" + }, + { + "path": "guides/validation.mdx", + "sourceSha256": "f060ee682789b323ce18e0f282ba6bb47a85accc912583a7600e69546dd9aeed", + "translationSha256": "41705496275d872f8bc796a36905e7b32d83543bbe2ec4c6397358c8d966eb59", + "status": "published" + }, + { + "path": "index.mdx", + "sourceSha256": "45b40d974470539641750f9473f39a6af74fbf999f39e8fb924c867abcc18370", + "translationSha256": "04593adc9aad838bc687e440fda28fe64be9df447b63c701c40a2bcf79dbe259", + "status": "published" + }, + { + "path": "networking.mdx", + "sourceSha256": "cf23c1a1df8c7e4b7835590d38786dc0574de771374c42dea5c1f5fdfc0079fd", + "translationSha256": "4b6031825369bb516f3abd6bf999229772434353308144b235b233e150048dbf", + "status": "published" + }, + { + "path": "observability/events.mdx", + "sourceSha256": "db2092362e0139e9ef1b6816eafd3f90ecfca59faad01fe1dfe0383057ce6bdb", + "translationSha256": "d3709a14f15c7476c3f8d97a5c5780e6b8eee6c55943a4b7a674c2b6833cb617", + "status": "published" + }, + { + "path": "observability/index.mdx", + "sourceSha256": "c99b35a322a98276ae9759c2443b7e1ebb77bb2a07b15391d6eff2d4e0d59fd1", + "translationSha256": "d60566bd9e3ebc682f1944aabe506efa61cedd31ed6838b72ca9b71524b7241f", + "status": "published" + }, + { + "path": "observability/logs.mdx", + "sourceSha256": "9e1e57fcde78990342ebd7619a1d5762f15dfb35c95142885f8c561bb9e35d40", + "translationSha256": "06586fb25aecfa5318d7a67520b8b99b616970f5dbbd24049c3ff251159a5ede", + "status": "published" + }, + { + "path": "observability/metrics.mdx", + "sourceSha256": "f95728b789c693cc7de9e37c2e8b07e8e35a8129fa754ac7aa8c296b97a7364a", + "translationSha256": "337126c327472bd64f8e5f0e5494a3e1399f319e41e170c8e16340fe9d33d76c", + "status": "published" + }, + { + "path": "platform/billing.mdx", + "sourceSha256": "a93fe73b92ee9d775f4b3e8182db6b719f6a1e8fa988b9f0a482eb5e24d29c62", + "translationSha256": "7d920ea7952eb162147eb35c33a0956f29ad523cd19f606d1d958b3d94e5e92f", + "status": "published" + }, + { + "path": "platform/known-issues.mdx", + "sourceSha256": "d9d69003cc9345a6059440d9f03894ceb437d7173be215e95403ba9b9210aec0", + "translationSha256": "8d20c3d5aeacfdfc86955fc4277144a9f3b7b270886fdbd766f47dfbb3ce5520", + "status": "published" + }, + { + "path": "platform/limits.mdx", + "sourceSha256": "5f2166c38b61c6dc032b4f0e4ac1fc1ae2c8a14db9af49ffd2371a7bf4649214", + "translationSha256": "4d463ed7179fd3b9c305631865fa2ba7aa847ca248c354ebc1ad432a4ffc149d", + "status": "published" + }, + { + "path": "platform/storage-and-recovery.mdx", + "sourceSha256": "30a114b2f76b0d2bbcf67cdd2a07630ef1c3992a526aa8915ca30a63d0ba18d4", + "translationSha256": "2f4d6033fd5c1a4109b6c780dd250706a2e683e9873cddadd1309836ecbbb775", + "status": "published" + }, + { + "path": "sandboxes/code-interpreter.mdx", + "sourceSha256": "d187221290fdbba78567a330e562a618cdd7d9fff31cc32c74b7ed9c1c67f241", + "translationSha256": "3b508b8aa5add4666881accdd81741009d02a618244fe98fd47db05a45320df0", + "status": "published" + }, + { + "path": "sandboxes/dashboard.mdx", + "sourceSha256": "828415eb0c46fce33f20bc2dae780262eacabf58127a590b1d681d54966db527", + "translationSha256": "4035c3b9ad7edbd3cd3f429e6d9bd72eaea388b43a5b61a90328322d449ec80f", + "status": "published" + }, + { + "path": "sandboxes/index.mdx", + "sourceSha256": "f07dd490dcb4e1b5376d256de65e13d79a37688fb8286b2dd6578e0eb14fdfbb", + "translationSha256": "73304ce4947c2de0ad7b51cc1ad77668bf02dd8f3ab2f3eb5a22b3859cd40262", + "status": "published" + }, + { + "path": "sandboxes/quickstart.mdx", + "sourceSha256": "c58f024fe163b5142bf554232363ffd74fce365d54cebc2f14ae997f9ab210dd", + "translationSha256": "7822a2b4582a091e1e0532111a05603f4f3bdff4e48356644eda54aa7be9b67b", + "status": "published" + }, + { + "path": "sandboxes/sdk-reference.mdx", + "sourceSha256": "2ef3c1a78d607f5daec121d792e10e66b25dc62538da865aaed3cc69a1947bd9", + "translationSha256": "0bec45d32f1779fc9002fbed5050487b0a836799148a2fd7c961f6a1e4d38510", + "status": "published" + }, + { + "path": "sandboxes/volumes.mdx", + "sourceSha256": "335158c3113ae1afa8cf0c966ffb5390d4e52b4e21965058318be124b5235438", + "translationSha256": "92fe068292d82320d7a70a2fdd916df826ac474e28dc8f692aa6ab116b825714", + "status": "published" + }, + { + "path": "studio/getting-started.mdx", + "sourceSha256": "3d6df5a941a22427bf6146f91cf795ceac7439aaf86d8c2d1213dcd3ba8ba2ae", + "translationSha256": "06b91622b49bfca73c4ff7f89bc40cbe700361448dd90598b8b1c70fc76933eb", + "status": "published" + }, + { + "path": "variables/index.mdx", + "sourceSha256": "2b605e838fc7dc268894a433dd4dfea5f3aa9b786ee80b334f9ae9edb242400c", + "translationSha256": "cd0306fa1bd477a09434391e0031b38425a39f68dcb311f40fc8d1dbc5bdcc16", + "status": "published" + }, + { + "path": "variables/references.mdx", + "sourceSha256": "21300a1c62e7d69d9bd9c935f95985ad1dc03fd5085ab6b862749b178f34f89c", + "translationSha256": "890d858d6d62082ce4a979bfb4ad0ce4f20e84667ec2b7411763019314cda39d", + "status": "published" + }, + { + "path": "variables/troubleshooting/reference-not-applied.mdx", + "sourceSha256": "2be66a188aa38cb545bd36437c19d928f70eedab58c3b38a7a2ae7720c5f25fa", + "translationSha256": "33337df338ceee5d5f49eee967492fe556420eb7bb822eb513102fd5946e6fd5", + "status": "published" + } + ] +} diff --git a/_locales/es/networking.mdx b/_locales/es/networking.mdx new file mode 100644 index 0000000..c3f0a31 --- /dev/null +++ b/_locales/es/networking.mdx @@ -0,0 +1,85 @@ +--- +description: "Cada servicio recibe un dominio onlizard.com con TLS automático. Asocia un hostname personalizado, verifica DNS, expón un puerto o elimina un dominio." +--- + + + +# Redes + +Cada servicio recibe un dominio generado `*.onlizard.com` con TLS automático en el momento en que se despliega, sin importar la región. Asocia tu propio hostname cuando estés listo para salir a producción. + + + +## Dominios generados + +El dominio predeterminado de un servicio se crea para ti. Muéstralo (o genera uno nuevo): + +```bash +lizard domain # show the service's current domain +lizard domain generate # generate a new *.onlizard.com subdomain +``` + +El object storage servido desde un [addon S3](/addons/storage) usa en su lugar un host de gateway con alcance regional (`s3-.onlizard.com`). + + + +## Asociar un dominio personalizado + +El hostname es un **argumento posicional** — no existe un subcomando `add`: + +```bash +lizard domain app.example.com --service web +``` + +Lizard devuelve los registros DNS que debes crear (un `CNAME` para el hostname y un registro `TXT` para la verificación). Agrégalos en tu proveedor de DNS. + + + +## Verificar + +Una vez que el DNS se haya propagado, activa el dominio: + +```bash +lizard domain verify app.example.com +``` + +Esto comprueba el registro `TXT` y activa el dominio. El TLS se aprovisiona automáticamente. + + + +## Eliminar un dominio + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes # alias, skip confirmation +``` + + + +## Exponer un puerto específico + +Si tu servicio sirve en un puerto no predeterminado, asocia el dominio a ese puerto: + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +## Servicios worker + +Un [servicio en modo worker](/deploy/workers) (`containerPort=0`) puede seguir mostrando un dominio generado, pero no sirve nada — no hay listener ni ruta de load balancer. No asocies un dominio personalizado a un worker. + + + +## Gestionar en el dashboard + +La vista **Dominios** en el dashboard (`lizard open`) muestra el estado de verificación y TLS de cada dominio y te permite agregar o eliminar hostnames visualmente. + + + +## Ver también + +- [`lizard domain`](/cli/domain) — la referencia completa de comandos. +- [Regiones](/deploy/regions) — co-ubicar servicios y addons para reducir la latencia. +- [De prototipo a un SaaS por el que pagan](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#from-vibe-coded-prototype-to-a-saas-people-pay-for) — dónde encaja un dominio personalizado entre las demás cosas que una app generada todavía necesita. diff --git a/_locales/es/observability/_meta.ts b/_locales/es/observability/_meta.ts new file mode 100644 index 0000000..4537554 --- /dev/null +++ b/_locales/es/observability/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Resumen", + logs: "Registros", + metrics: "Métricas y costo", + events: "Eventos e historial", +}; diff --git a/_locales/es/observability/events.mdx b/_locales/es/observability/events.mdx new file mode 100644 index 0000000..02320b9 --- /dev/null +++ b/_locales/es/observability/events.mdx @@ -0,0 +1,47 @@ +--- +description: "Lee la línea de tiempo de despliegue de un servicio y el estado en vivo de las réplicas con lizard events, y encuentra el mismo historial en la vista Despliegues del dashboard." +--- + + + +# Eventos e historial + +`lizard events` muestra el historial de despliegues de un servicio y el estado en vivo de sus réplicas: la línea de tiempo de lo que se desplegó y de lo que se está ejecutando ahora mismo. + + + +## Ver eventos + +```bash +lizard events # deploy history + replica status +lizard events --service api # a specific service +lizard events --limit 25 # show more entries (default 10) +``` + +Cada entrada cubre una acción de despliegue o escalado y el estado resultante de las réplicas, para que puedas responder de un vistazo "qué cambió y si está saludable". + + + +## Estado rápido + +Para una vista rápida de todos los servicios del proyecto — estado y URL — usa: + +```bash +lizard ps +lizard status # the current directory's workspace/project/service link +``` + + + +## Panel + +La vista **Despliegues** del dashboard (`lizard open`) muestra el mismo historial como una línea de tiempo, con un panel de detalles por despliegue (logs de compilación, commit, estado) y el estado de salud de cada réplica. + + + +## Ver también + +- [Despliegues](/concepts/deployments) — el ciclo de vida del despliegue. +- [Logs](/observability/logs) — logs de ejecución, compilación y reinicio. +- [Metrics & Cost](/observability/metrics) — uso de recursos y facturación. +- [`lizard events`](/cli/events) — la referencia completa de comandos. diff --git a/_locales/es/observability/index.mdx b/_locales/es/observability/index.mdx new file mode 100644 index 0000000..c0dde79 --- /dev/null +++ b/_locales/es/observability/index.mdx @@ -0,0 +1,19 @@ +--- +description: "Mira lo que están haciendo tus servicios: transmite logs, sigue métricas y costos, y revisa el historial de deploys y réplicas." +--- + + + +# Observabilidad + +Mira lo que están haciendo tus servicios: transmite logs, sigue métricas y costos, y revisa el historial de deploys y réplicas. + + + +## En esta sección + +- [Logs](/observability/logs) — logs en vivo e históricos, incluidos los logs de compilación y reinicio. +- [Metrics & Cost](/observability/metrics) — uso de recursos y lo que cuesta. +- [Events & History](/observability/events) — cronología de deploys y estado por réplica. + +Cada vista aquí también tiene un formulario `--json`, que es lo que lee un agente de programación con IA cuando un deploy falla — consulta [despliegue desde Claude Code](https://lizard.build/blog/deploy-from-claude-code). diff --git a/_locales/es/observability/logs.mdx b/_locales/es/observability/logs.mdx new file mode 100644 index 0000000..a9af06e --- /dev/null +++ b/_locales/es/observability/logs.mdx @@ -0,0 +1,71 @@ +--- +description: "Transmite logs de ejecución en tiempo real, consulta logs de compilación después de un deploy fallido y obtén la cola de logs alrededor de un reinicio, desde la CLI o el dashboard." +--- + +# Logs + +Lizard captura logs de **ejecución**, logs de **compilación** y la cola de logs alrededor de **reinicios**. Transmítelos en vivo en tu terminal o consúltalos en el dashboard. + + + +## Logs de ejecución + +```bash +lizard logs # last 200 runtime lines, then live tail +lizard logs --service api # a specific service +lizard logs --tail 1000 # more history (max 1000) +lizard logs --level error # filter by level +``` + + + +### Comportamiento con `--json` + +`lizard logs --json` **no** es una transmisión: devuelve las últimas 200 líneas (puedes cambiarlo con `--tail N`, máximo 1000) y finaliza. Úsalo para instantáneas y scripts. Transmite en vivo solo sin `--json` cuando quieras una cola interactiva. + + + +## Logs de compilación + +```bash +lizard logs --build # the most recent build's logs +``` + +Esto es lo primero que debes revisar cuando falla un deploy: léelo, corrige la causa y luego `lizard redeploy`. Consulta [Proceso de compilación](/concepts/build-pipeline). + + + +## Logs de reinicio / fallo + +Cuando una réplica falla o se reinicia, obtén la cola de logs alrededor del evento: + +```bash +lizard logs --restart latest # the most recent restart +lizard logs --restart # a specific restart +lizard logs --restarts # list recent restarts +``` + + + +## Paginación del historial + +`lizard service logs` permite paginar ventanas más antiguas: + +```bash +lizard service logs --service api --tail all # full history (no follow) +lizard service logs --service api --page 2 # older window (implies --tail 200) +``` + + + +## Panel + +El dashboard (`lizard open`) transmite logs de ejecución y de compilación con filtros de búsqueda y nivel, y muestra la salida de compilación por deploy en la vista de **Despliegues**. + + + +## Ver también + +- [`lizard logs`](/cli/logs) — la referencia completa de comandos. +- [Events & History](/observability/events) — historial de deploys y estado de las réplicas. +- [Desplegar desde Claude Code](https://lizard.build/blog/deploy-from-claude-code) — logs escritos para que los lea un agente, no solo tú. diff --git a/_locales/es/observability/metrics.mdx b/_locales/es/observability/metrics.mdx new file mode 100644 index 0000000..cbbef37 --- /dev/null +++ b/_locales/es/observability/metrics.mdx @@ -0,0 +1,50 @@ +--- +description: "Supervisa CPU, memoria, red y disco de un servicio, consulta cuánto cuesta la escala actual y actúa según lo que muestren los números." +--- + + + +# Métricas y costo + +Supervisa CPU, memoria, red y disco de un servicio — y consulta cuánto está costando — desde la CLI o el panel. + + + +## Ver métricas + +```bash +lizard metrics # CPU / memory / network / disk +lizard metrics --service api # a specific service +lizard metrics --range # time window +lizard metrics --watch # live-updating view +``` + + + +## Incluir costo + +```bash +lizard metrics --cost +``` + +Añade cifras de costo junto al uso de recursos para que puedas ver el precio de la escala actual. + + + +## Panel + +El panel (`lizard open`) muestra estos datos como gráficos en la vista **Metrics / Observabilidad**, y la vista **Uso** desglosa el consumo y la facturación de todo el proyecto. Ábrelo con: + +```bash +lizard open +``` + + + +## Actuar según lo que ves + +- CPU/memoria altas → escala hacia arriba: `lizard scale --service api --cpu 2 --memory 2048`. +- Carga sostenida → añade réplicas: `lizard scale --service api --replicas 3`. +- Presión de disco en un addon → amplía el almacenamiento: `lizard scale --service postgres --storage 8192`. + +Consulta [Scaling](/deploy/scaling). diff --git a/_locales/es/platform/_meta.ts b/_locales/es/platform/_meta.ts new file mode 100644 index 0000000..50d2600 --- /dev/null +++ b/_locales/es/platform/_meta.ts @@ -0,0 +1 @@ +export default { billing: "Facturación y créditos", limits: "Límites", 'storage-and-recovery': "Almacenamiento y recuperación", 'known-issues': "Problemas conocidos" }; diff --git a/_locales/es/platform/billing.mdx b/_locales/es/platform/billing.mdx new file mode 100644 index 0000000..30dd615 --- /dev/null +++ b/_locales/es/platform/billing.mdx @@ -0,0 +1,63 @@ +--- +description: "Lizard pay as you go: tarifas de recursos, créditos de la cuenta, recarga automática opcional, comisiones de pago y qué ocurre cuando tu saldo se agota." +--- + + + +# Pago por uso + +Lizard no tiene suscripción mensual ni costo por usuario para las cuentas estándar. Añade créditos a tu cuenta y paga por los recursos que usas. Los créditos comprados que no uses permanecen en tu saldo, así que un mes tranquilo no requiere comprar otro paquete. + + + +## Tarifas de recursos + +Los precios están en dólares estadounidenses. + +| Recurso | Tarifa | +| --- | ---: | +| CPU | $0.000006948 por vCPU-segundo | +| Memory | $0.000003474 por GB-segundo | +| Persistent Volumes | $0.000000054 por GB-segundo | +| Managed Object Storage | $0.0135 por GB-mes | +| Outgoing traffic | $0.045 por GB, desde el primer byte | + +El tráfico entrante no tiene costo. Las apps, Managed Postgres, Managed Redis y Sandboxes usan las mismas tarifas de recursos aplicables. Los límites de recursos de la cuenta siguen aplicándose; añadir créditos no aumenta esos límites. + +Por ejemplo, un vCPU y 1 GB de memoria usados durante una hora cuestan $0.0375192 en cómputo. El almacenamiento, el tráfico saliente y las comisiones de pago pueden sumarse a ese importe. Este es un ejemplo de costo de recursos, no del importe cobrado por una recarga. + +Consulta los [precios actuales](https://lizard.build/pricing) para ver la oferta completa. La facturación Enterprise sigue tu contrato. + + + +## Saldo de la cuenta + +El uso en un espacio de trabajo se descuenta del saldo de la cuenta de su propietario. Añadir miembros no tiene costo por usuario. La página Credits muestra tu saldo, compras y cualquier crédito que venza. + +- **Los créditos comprados no vencen.** No se restablecen cada mes. +- **Los créditos de prueba vencen.** Las cuentas nuevas reciben $10 en créditos de prueba, válidos durante 31 días. +- **Los créditos promocionales pueden vencer.** Revisa los términos y la fecha de vencimiento que se muestran para la concesión. + +Un saldo comprado paga el uso; no es un descuento sobre la tarifa del recurso. No lo restes otra vez al comparar costos con otro proveedor. + + + +## Recargas y comisiones + +Abre **Credits** en la configuración de la cuenta para añadir fondos. Antes de confirmar, la pantalla de recarga muestra el importe mínimo, el importe de crédito, la comisión de pago y el cargo total. Una recarga mínima no es un cargo mensual. + +La recarga automática es opcional. Elige el umbral de saldo y el importe en tu configuración de Credits. Puedes desactivarla allí. Desactivar la recarga automática no detiene los recursos ni termina los cargos por su uso. + + + +## Saldo bajo o agotado + +Lizard te avisa cuando tu saldo es bajo. Si tu saldo se agota y un pago no lo restablece, la creación de recursos puede quedar restringida y los servicios en ejecución pueden pausarse después del período de gracia aplicable. Revisa tu página Credits para ver las condiciones de la cuenta y restablece el saldo antes de que termine el período de gracia para evitar una pausa. + + + +## Apps inactivas y datos almacenados + +Una app puede usar memoria y CPU incluso cuando no tiene solicitudes. Detén la app para detener el uso de cómputo. Persistent Volumes y Managed Object Storage siguen acumulando cargos de almacenamiento mientras conserves datos, incluso cuando la app está detenida. + +Consulta [almacenamiento y recuperación](/platform/storage-and-recovery) antes de eliminar datos. Lee [métricas](/observability/metrics) para comparar los límites configurados con el uso medido. diff --git a/_locales/es/platform/known-issues.mdx b/_locales/es/platform/known-issues.mdx new file mode 100644 index 0000000..798eb49 --- /dev/null +++ b/_locales/es/platform/known-issues.mdx @@ -0,0 +1,51 @@ +--- +description: "Limitaciones actuales del ciclo de vida de Sandboxes, límites de recuperación de despliegues y precedencia de la configuración de compilación que debes revisar antes de depender de un flujo de trabajo." +--- + + + +# Problemas conocidos + +Esta página registra comportamientos que requieren precaución o una versión verificada. Una corrección de código en revisión no es una garantía sobre un servicio en ejecución. + + + +## Pausa y vencimiento del sandbox + +La pausa está pensada para congelar el tiempo de vida restante. Un conflicto entre el reloj del nodo y un proceso de limpieza independiente puede finalizar un sandbox en pausa después de su fecha límite original. El reinicio del node-agent y la reanudación de un sandbox sin vencimiento también necesitan la corrección del ciclo de vida. + +Hasta que esa corrección haya superado una prueba en vivo y haya llegado a tu región, no dependas solo de la pausa para conservar el estado a largo plazo. Guarda los archivos en `/data` en un Persistent Volumes, o almacena el estado de la aplicación en una base de datos o en object storage. La memoria del host no es una copia de seguridad. Usa un tiempo de vida explícito y libera el sandbox cuando termine la tarea. + + + +## Redeploy no es rollback + +`lizard redeploy` vuelve a compilar el código fuente seleccionado con la configuración actual. No selecciona una compilación anterior. Una compilación fallida y un inicio fallido tienen efectos distintos; inspecciona el servicio activo y sus logs antes de elegir un paso de recuperación. No asumas que todos los runtimes mantienen la versión anterior sirviendo tráfico tras un inicio fallido. + + + +## Precedencia de Dockerfile + +Los comandos explícitos de compilación o inicio tienen prioridad sobre un Dockerfile del repositorio. Borra esas anulaciones al seleccionar `dockerfilePath`. Una actualización de la configuración puede iniciar por sí misma una compilación, así que revisa los eventos antes de enviar otro redeploy. Consulta la [solución de problemas de Dockerfile](/deploy/troubleshooting/incomplete-dockerfile). + + + +## Plantillas y MCP + +La API actual de creación de Sandboxes acepta las dos plantillas integradas. Las instrucciones que usan `lizard push` para plantillas personalizadas no coinciden con la CLI pública actual. + +Lizard Skill usa Lizard CLI. Ese flujo de trabajo no expone un transporte MCP. Alojar tu propio servidor MCP remoto es un despliegue de aplicación independiente; consulta la [guía](/guides/deploy-mcp-server). + + + +## Cambios de puerto del servicio: corregido y verificado el 2026-09-09 + +La comprobación del 7 de septiembre detectó HTTP 503 después de cambiar un servicio subido del puerto `3000` al `80`, a pesar de que el proceso estaba listo. La corrección en producción ahora aplica el puerto elegido al servicio en ejecución y conserva un puerto explícito durante la subida y la recompilación. Una comprobación en vivo del cambio de puerto se aprobó el 9 de septiembre. Revisa la URL pública después de un despliegue, además del estado del servicio. + + + +## Archivos subidos y códigos de salida de compilaciones fallidas: corregido + +Lizard CLI 0.3.95 excluye las entradas de metadatos `._*` de macOS de las subidas de código fuente y devuelve un código de salida distinto de cero para compilaciones fallidas en la nube. Actualiza las versiones anteriores de la CLI; `COPYFILE_DISABLE` ya no es necesario. Las [comprobaciones de frameworks](/framework-guides/validation) cubren subidas desde macOS con la CLI actual. + +Una compilación exitosa por sí sola no demuestra que la aplicación funcione. Revisa la URL pública, las rutas, los formularios y las operaciones de datos después del despliegue. diff --git a/_locales/es/platform/limits.mdx b/_locales/es/platform/limits.mdx new file mode 100644 index 0000000..c1411e4 --- /dev/null +++ b/_locales/es/platform/limits.mdx @@ -0,0 +1,49 @@ +--- +description: "Consulta los límites de réplicas de aplicaciones, los recursos y tiempos de espera de Sandboxes, las regiones y el alcance de las cuotas de la cuenta antes del despliegue." +--- + + + +# Límites + +Los límites dependen del recurso, el plan y la cuenta. Una configuración por réplica no es el total disponible para un servicio o una cuenta. Consulta tu plan actual y el resultado de la solicitud de creación o escalado antes de dimensionar una carga de trabajo. + + + +## Aplicaciones + +| Ajuste | Ámbito | Qué comprobar | +|---|---|---| +| CPU and memory | Cada réplica | Tres réplicas con un límite de 2 vCPU / 2 GiB tienen un límite configurado combinado de 6 vCPU / 6 GiB. Esto no es una previsión de uso. | +| Replica count | Servicio y plan | La API acepta 1–10; los límites del plan pueden reducir ese rango. Las comprobaciones del plan Standard permiten 1, o 5 para Pro/Enterprise, con anulaciones a nivel de cuenta. | +| Límite de recursos de la cuenta | Titular de la cuenta | Un segundo proyecto no necesariamente crea una segunda cuota. Solicita el límite efectivo de la cuenta antes de planificar un despliegue grande. | +| Worker mode | Servicio | `containerPort=0` se ejecuta sin un listener HTTP ni una ruta pública del balanceador de carga. | +| Custom domain | Nombre de host | No se aceptan dominios personalizados comodín. Usa un nombre de host específico y completa las comprobaciones de propiedad y DNS. | + +Las aplicaciones pueden usar distintos runtimes. No asumas que todas las aplicaciones tienen el mismo aislamiento de micro-VM de Firecracker que Sandboxes. + +## Sandboxes + +| Ajuste | API de creación actual | +|---|---| +| CPU and memory | 4 vCPU / 4096 MiB | +| Plantillas | `base`, `code-interpreter-v1` | +| Duración predeterminada de la API sin procesar | `timeoutMs: 0`, sin vencimiento | +| Duración predeterminada de Lizard SDK | 300000 ms, cinco minutos | +| Rango de vida explícito | Milisegundos enteros de 0 a 2147483647 | +| Actualizar una vida útil | Al menos 1000 ms; no es un temporizador de inactividad | +| Adjuntar volumen persistente | Un sandbox a la vez, en el nodo del volumen | + +Pasa un tiempo de vida explícito desde los scripts. Por ejemplo, `--timeout 300000` deja claro el límite previsto en todas las versiones de Lizard CLI. Consulta [pausa y expiración](/platform/known-issues#sandbox-pause-and-expiration) antes de dejar una sesión en pausa. + + + +## Regiones + +Las regiones configuradas actualmente incluyen US East (Virginia), `us-east-1`, y EU West (Limburg), `eu-west-lim-a`. Que una región aparezca en el catálogo no garantiza capacidad disponible para cada recurso. Consulta las opciones de región al crear el recurso; un sandbox que use un volumen existente debe ejecutarse en el nodo de ese volumen. + + + +## Antes de aumentar la escala + +Consulta conjuntamente el plan activo, la configuración por réplica, el límite de la cuenta, el límite de conexiones de la base de datos y el crecimiento del almacenamiento. Usa [scaling](/deploy/scaling), [metrics](/observability/metrics) y [pricing](https://lizard.build/pricing) para comparar la capacidad configurada con el uso medido. diff --git a/_locales/es/platform/storage-and-recovery.mdx b/_locales/es/platform/storage-and-recovery.mdx new file mode 100644 index 0000000..36942f9 --- /dev/null +++ b/_locales/es/platform/storage-and-recovery.mdx @@ -0,0 +1,53 @@ +--- +description: "Elige el almacenamiento para los datos de la aplicación y los archivos del sandbox. Comprende los adjuntos, los fallos del host, las exportaciones y la recuperación antes de eliminar o reemplazar un recurso." +--- + + + +# Almacenamiento y recuperación + +Elige el almacenamiento según los datos que deben sobrevivir a un reinicio del proceso, un nuevo despliegue o un fallo del host. Son eventos diferentes. El almacenamiento persistente no proporciona por sí solo una copia de seguridad, un punto de restauración ni alta disponibilidad. + +| Datos | Dónde mantenerla | Límite | +|---|---|---| +| Registros de la aplicación | Managed Postgres u otra base de datos | Un reinicio es distinto de restaurar datos eliminados o dañados. Prueba una ruta independiente de exportación y restauración. | +| Datos de caché y cola | Managed Redis | Decide si la carga de trabajo puede reconstruir su estado o necesita su propio plan de recuperación. | +| Archivos compartidos por aplicaciones | Managed Object Storage | Configura la política de acceso del bucket antes de subir datos privados. El bucket `default` creado automáticamente es de lectura pública. | +| Archivos necesarios para Sandboxes posteriores | Persistent Volumes, montado en `/data` | Un adjunto de sandbox a la vez; el volumen permanece en su nodo. | +| Archivos temporales del sandbox | El sistema de archivos guest fuera de `/data` | No esperes que sigan ahí después de que termine el sandbox o se reemplace el guest. | +| Estado de proceso pausado | Memoria del host | La pausa no es una instantánea duradera; un fallo del host pierde ese estado. | + + + +## Conservar archivos después de que termine un sandbox + +Crea un Persistent Volumes en el mismo proyecto, adjúntalo al crear el sandbox y escribe en `/data`. Termina el primer sandbox antes de adjuntar el volumen al siguiente. Consulta el [ejemplo completo](/sandboxes/volumes). + + + +## Planificar una restauración de base de datos + +Antes de una migración o una versión que cambie datos: + +1. Elige un método de exportación para la base de datos y la versión en uso. +2. Almacena la exportación por separado del recurso que se va a cambiar. +3. Restaura en una base de datos de prueba independiente y verifica que la aplicación pueda leerla. +4. Registra la duración de la restauración y los datos más recientes incluidos en la exportación. + +No asumas copias de seguridad programadas, recuperación a un momento dado, replicación multinodo ni una garantía de tiempo de restauración por el hecho de que la base de datos sea administrada. Confirma el acuerdo de servicio actual y los controles disponibles para tu recurso. + + + +## Referencias de entorno + +Una aplicación debe leer su conexión a la base de datos desde una referencia de entorno. Una cadena de conexión es una credencial; evita imprimirla para verificar una actualización. Una comprobación de conexión como `SELECT 1` demuestra más que ver la variable en un shell. + + + +## Guías relacionadas + +- [Managed Postgres](/addons/postgres) +- [Managed Redis](/addons/redis) +- [Managed Object Storage](/addons/storage) +- [Persistent Volumes](/sandboxes/volumes) +- [Recuperación de despliegues](/concepts/deployments#failed-releases-and-recovery) diff --git a/_locales/es/sandboxes/_meta.ts b/_locales/es/sandboxes/_meta.ts new file mode 100644 index 0000000..c777643 --- /dev/null +++ b/_locales/es/sandboxes/_meta.ts @@ -0,0 +1,8 @@ +export default { + index: "Resumen", + quickstart: "Inicio rápido", + 'sdk-reference': "Referencia del SDK", + 'code-interpreter': "Intérprete de código", + volumes: "Persistent Volumes", + dashboard: "Panel", +}; diff --git a/_locales/es/sandboxes/code-interpreter.mdx b/_locales/es/sandboxes/code-interpreter.mdx new file mode 100644 index 0000000..9e4ce72 --- /dev/null +++ b/_locales/es/sandboxes/code-interpreter.mdx @@ -0,0 +1,111 @@ +--- +description: "CodeSandbox mantiene un kernel con estado entre llamadas, por lo que las variables y las importaciones persisten. Ejecuta Python, JavaScript o Bash como lo hace un agente." +--- + + + +# Intérprete de código + +`CodeSandbox` amplía un [sandbox](/sandboxes) normal con un **kernel con estado**: las variables, las importaciones y las definiciones de funciones persisten entre llamadas, igual que en un cuaderno Jupyter. Es la herramienta adecuada cuando un agente de IA genera y ejecuta código de forma incremental. + +Se inicia desde la plantilla `code-interpreter-v1` (Python 3.14 + Node.js 26, con una API de ejecución de código en el puerto 8080) y admite **Python, JavaScript y Bash** de forma predeterminada. + + + +## Ejecutar código + +```ts +import { CodeSandbox } from '@lizard-build/sdk'; + +// Every sandbox belongs to a project — usage is metered per project +const sandbox = await CodeSandbox.create({ project: 'my-project' }); // defaults to 'code-interpreter-v1' + +await sandbox.runCode('x = 42'); +const result = await sandbox.runCode('print(x * 2)'); +console.log(result.stdout); // "84\n" — x survived from the previous call + +await sandbox.kill(); +``` + +`runCode(code, opts?)` devuelve un `Execution`: + +| Campo | Descripción | +|---|---| +| `stdout` / `stderr` | Flujos de salida capturados | +| `results` | Resultados enriquecidos (valores y cualquier imagen / gráfico generado) | +| `error` | Un `ExecutionError` (`name`, `message`, `traceback`) si el código produjo una excepción | +| `executionCount` | Contador monótono del kernel | + + + +## Elegir un lenguaje + +El valor predeterminado es Python. Pasa `language` para una ejecución puntual en otro entorno de ejecución: + +```ts +const js = await sandbox.runCode('1 + 1', { language: 'javascript' }); +console.log(js.results[0].data); // "2" + +await sandbox.runCode('echo "$(uname -s)"', { language: 'bash' }); +``` + + + +## Salida en streaming + +Para celdas de ejecución prolongada, transmite stdout/stderr a medida que se genera en lugar de esperar al resultado: + +```ts +await sandbox.runCode('for i in range(5): print(i)', { + onStdout: (line) => process.stdout.write(line), + onStderr: (line) => process.stderr.write(line), + onResult: (r) => console.log('result:', r), + onError: (e) => console.error('error:', e.name, e.message), +}); +``` + + + +## Contextos aislados + +Un **contexto** es un espacio de nombres independiente dentro del mismo sandbox: usa uno por sesión de agente o por usuario, para que sus variables nunca entren en conflicto. + +```ts +const a = await sandbox.createContext({ language: 'python' }); +const b = await sandbox.createContext({ language: 'python' }); + +await sandbox.runCode('secret = 1', { context: a }); +await sandbox.runCode('print(secret)', { context: b }); // NameError — b never saw it + +await sandbox.listContexts(); +await sandbox.restartContext(a); // clear all variables/state +await sandbox.deleteContext(b); // free its resources +``` + +Pasa **o bien** `context` **o** `language` a `runCode`, no ambos: un contexto ya tiene un lenguaje asociado. + + + +## Crear un checkpoint de una sesión + +Como `CodeSandbox` es un sandbox, [pausar y reanudar](/sandboxes/quickstart#pause-and-resume) funciona igual. Instala una pila pesada de dependencias una vez, pausa y reanuda más tarde con el estado del kernel intacto: + +```ts +const sandbox = await CodeSandbox.create({ project: 'my-project' }); +await sandbox.runCode('import subprocess; subprocess.run(["pip", "install", "scikit-learn"])'); +const id = sandbox.sandboxId; +await sandbox.pause(); + +// Later — resume with packages and kernel variables already in place +const resumed = await CodeSandbox.connect(id); +const out = await resumed.runCode('import sklearn; print(sklearn.__version__)'); +console.log(out.stdout); +await resumed.kill(); +``` + + + +## Ver también + +- [Referencia del SDK](/sandboxes/sdk-reference) — todos los métodos de `CodeSandbox` y las opciones de `runCode`. +- [Persistent Volumes](/sandboxes/volumes) — adjunta almacenamiento que perdura más allá de un único sandbox. diff --git a/_locales/es/sandboxes/dashboard.mdx b/_locales/es/sandboxes/dashboard.mdx new file mode 100644 index 0000000..79337f5 --- /dev/null +++ b/_locales/es/sandboxes/dashboard.mdx @@ -0,0 +1,63 @@ +--- +description: "Crea e inspecciona sandboxes manualmente desde la página Sandboxes de un proyecto: claves de API, shells en vivo, controles de ciclo de vida, snapshots y volúmenes." +--- + + + +# Panel de Sandboxes + +Cada proyecto tiene una página de **Sandboxes** para crear e inspeccionar sandboxes manualmente; es útil para depurar el entorno de un agente, abrir un shell interactivo o verificar rápidamente qué código se produjo. Abre un proyecto y selecciona **Sandboxes** en la barra lateral (`///sandboxes`). + +La página tiene tres pestañas: **Sandboxes**, **Volúmenes** y **Instantáneas**. + + + +## Obtener una clave de API + +Si todavía no has usado sandboxes, el estado vacío te guía para crear una **clave de API** para el SDK. La clave se muestra **una sola vez**: cópiala de inmediato; no se puede recuperar después. Guárdala como `LIZARD_API_KEY` (consulta el [Quickstart](/sandboxes/quickstart#authenticate)). + + + +## Crear un sandbox + +Haz clic en **New Sandbox** y configura: + +- **Snapshot** — la [plantilla](/sandboxes#templates) desde la que arrancar (`base` o `code-interpreter-v1`). +- **Location** — la región donde se ejecutará (por defecto, la disponible más cercana). +- **Resources** — las plantillas actuales usan 4 vCPU y 4096 MiB de RAM; estas no son opciones de tamaño por creación. + +Los sandboxes creados aquí no tienen tiempo de espera: se ejecutan hasta que los detengas. + + + +## Inspeccionar un sandbox en ejecución + +Al seleccionar un sandbox, se abre un panel de detalles con dos pestañas. + +**Overview** muestra su ID, plantilla, estado, región y CPU/memoria, además de: + +- **Exposed ports** — cada puerto abierto con [`getHost`](/sandboxes/quickstart#exposing-a-port), cada uno con una URL pública `https://…onlizard.com` que puedes copiar y abrir directamente. +- **SSH access** — cuando está disponible, un comando `ssh root@ -p ` listo para pegar y la contraseña generada. + +**Terminal** te da un shell en el navegador directamente dentro de la micro-VM (respaldado por SSH), para que puedas explorar sin salir del panel. + +Los sandboxes en vivo informan el uso de CPU y memoria en tiempo real en la lista; los que están en pausa o detenidos informan cero. + + + +## Ciclo de vida + +- **Kill Sandbox** (en el panel de detalles) lo termina de inmediato y libera sus recursos, incluida la desconexión de cualquier [volumen](/sandboxes/volumes). +- **Pause / resume** se controla desde el [SDK](/sandboxes/quickstart#pause-and-resume); un sandbox en pausa aparece aquí como **Paused** y no consume cómputo bajo demanda. + + + +## Instantáneas + +La pestaña **Instantáneas** enumera las plantillas desde las que puede arrancar un sandbox: las integradas `base` y `code-interpreter-v1`. Un comando de carga de plantilla personalizada no forma parte del CLI público actual. Cada entrada muestra su vCPU/memoria predeterminados y su descripción. + + + +## Volúmenes + +La pestaña **Volúmenes** gestiona el [almacenamiento persistente](/sandboxes/volumes): crea un volumen con un nombre y un tamaño, y ve a qué sandbox está conectado cada uno. diff --git a/_locales/es/sandboxes/index.mdx b/_locales/es/sandboxes/index.mdx new file mode 100644 index 0000000..240eba5 --- /dev/null +++ b/_locales/es/sandboxes/index.mdx @@ -0,0 +1,88 @@ +--- +description: "Un sandbox es una micro-VM aislada de Firecracker que inicias en milisegundos, ejecutas código en ella y descartas. La primitiva de cómputo detrás de los agentes de IA." +--- + +# Sandboxes + +Un **sandbox** es una micro-VM aislada de Firecracker que levantas bajo demanda, ejecutas código dentro y desmontas cuando terminas. Cada uno es un entorno Linux completo con su propio sistema de archivos, red y espacio de nombres de procesos — iniciado en milisegundos, no en minutos. + +Sandboxes son la primitiva de cómputo detrás de los agentes de IA, intérpretes de código, evals y trabajos de estilo CI en Lizard. Mientras que un [service](/concepts/architecture) es un despliegue de larga duración vinculado a un repo, un sandbox es **efímero, programable y desechable** — crea un sandbox para cada tarea dentro de la capacidad disponible para tu cuenta. + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const { stdout } = await sandbox.process.exec('echo "hello from Lizard"'); +console.log(stdout); // hello from Lizard +await sandbox.kill(); +``` + + + +## Cuándo usar un sandbox + +| Usa un **sandbox** cuando… | Usa un **service** cuando… | +|---|---| +| Un agente necesita ejecutar código no confiable o generado | Estás desplegando una app que permanece activa | +| Quieres una máquina Linux nueva y desechable por tarea | Quieres una URL `..onlizard.com` estable y TLS | +| Necesitas distribuir muchos trabajos aislados a la vez | Tienes un único proceso siempre activo | +| La carga de trabajo es de corta duración o se pausa | La carga de trabajo está respaldada por git y se vuelve a desplegar automáticamente | + +Una vez que un agente ha producido una app funcional dentro de un sandbox, puedes promoverla a un service persistente con [`lizard up`](/deploy/upload) — sin necesidad de Dockerfile. + + + +## Qué los hace rápidos + +- **Micro-VMs de Firecracker** — un invitado Linux independiente para cada sandbox. Los runtimes de aplicaciones tienen distintas reglas de aislamiento. La virtualización por hardware separa el invitado del host. Controla las credenciales y el acceso de red del código en el que no confías. +- **Pausar y reanudar** — al pausar se congelan las vCPU de la micro-VM. La memoria, el sistema de archivos y los procesos en ejecución se mantienen tal como están, así que al reanudar se retoma exactamente donde se quedó — sin reinstalar paquetes ni recalentar cachés. Esto es lo que permite que las sesiones de agentes de larga duración sobrevivan entre invocaciones separadas. El estado se mantiene en la memoria del host en lugar de escribirse en disco, por lo que no sobrevive a un fallo del host. Consulta [pause & resume](/sandboxes/quickstart#pause-and-resume). +- **Arranque desde una plantilla** — cada nodo preconstruye una instantánea dorada por plantilla, así que `create` es una restauración, no un arranque en frío. + + + +## Plantillas + +Un sandbox arranca desde una **template** (también llamada *snapshot* en el dashboard). Hay dos integradas: + +| Plantilla | Contenido | Ideal para | +|---|---|---| +| `base` | Debian Linux, Node.js 26 y Lizard CLI | Entornos de shell y compilación de uso general | +| `code-interpreter-v1` | Python 3.14 + Node.js 26, con una API HTTP de ejecución de código en el puerto 8080 | Intérpretes de código con IA — contrólalo con [`CodeSandbox`](/sandboxes/code-interpreter) | + +`base` es la opción predeterminada. La API pública de creación acepta estos dos nombres de plantilla. No expone un flujo de carga de plantillas personalizadas. + + + +## Ciclo de vida + +Un sandbox pasa por tres estados: + +``` +create ──▶ running ⇄ paused ──▶ stopped + (killed or expired) +``` + +- **running** — el invitado puede ejecutar comandos, trabajar con archivos y servir puertos expuestos. +- **paused** — las vCPU se detienen. La memoria del invitado y el estado de los procesos permanecen en el host; esto no es una instantánea duradera ni una copia de seguridad. +- **stopped** — el sandbox terminó por eliminación o expiración. Su sistema de archivos local ya no está disponible. + +El SDK envía por defecto una duración de cinco minutos. La API de creación sin procesar acepta `timeoutMs: 0` para no tener expiración. Pasa un tiempo de espera explícito cuando un script deba comportarse igual en todos los clientes, y libera el sandbox cuando termine la tarea. Los comandos no reinician la duración. + +La pausa está pensada para preservar el tiempo de ejecución restante. Revisa el [problema actual del ciclo de vida](/platform/known-issues#sandbox-pause-and-expiration) antes de depender de una pausa más larga que la fecha límite original. Los archivos persistentes deben ir en un [volume](/sandboxes/volumes); un invitado en pausa no sobrevive a un fallo del host. + + + +## Recursos y límites + +Cada sandbox se ejecuta con **4 vCPU / 4096 MiB RAM** fijos. La API pública de creación no tiene una configuración de tamaño por sandbox. Cada sandbox hereda los recursos de su plantilla. + +La región se elige automáticamente según la capacidad disponible; en el dashboard puedes fijar una. No asumas que las cuotas de app y la capacidad de sandbox usan las mismas reglas de aplicación. Consulta [limits](/platform/limits). + + + +## Formas de usar Sandboxes + +| Superficie | Ideal para | Empieza aquí | +|---|---|---| +| **SDK** (JS / Python) | Agentes, apps y scripts — incluida la ejecución con estado y en varios lenguajes mediante [`CodeSandbox`](/sandboxes/code-interpreter) | [Quickstart](/sandboxes/quickstart) · [SDK Reference](/sandboxes/sdk-reference) | +| **Panel** | Creación manual, terminal, SSH, monitoreo | [Panel](/sandboxes/dashboard) | diff --git a/_locales/es/sandboxes/quickstart.mdx b/_locales/es/sandboxes/quickstart.mdx new file mode 100644 index 0000000..fb2a37c --- /dev/null +++ b/_locales/es/sandboxes/quickstart.mdx @@ -0,0 +1,237 @@ +--- +description: "Inicia tu primer sandbox con Lizard SDK: instala, crea una clave de API, elige un proyecto, ejecuta código, mueve archivos, expón un puerto y pausa." +--- + + + +# Inicio rápido de Sandboxes + +Inicia un sandbox, ejecuta código en él, expón un puerto y ponlo en pausa con Lizard SDK. + + + +## Instalar + +```bash +# JavaScript / TypeScript +npm install @lizard-build/sdk + +# Python +pip install lizard-sdk +``` + + + +## Autenticación + +Sandboxes se autentica con una **clave de API**. Crea una en el panel (**Sandboxes → Primeros pasos → Nueva clave de API**) — se muestra una sola vez, así que cópiala de inmediato. + +Configúrala en tu entorno y el SDK la detectará automáticamente: + +```bash +export LIZARD_API_KEY="" +``` + +También puedes pasarla explícitamente: `Sandbox.create('base', { apiKey, project })`. + + + +## Elegir un proyecto + +Cada sandbox pertenece a un proyecto — el uso se mide por proyecto, así que la API rechaza una creación si no se indica uno. Indica el proyecto por su ID, slug o nombre. + +El cliente `Lizard` fija un proyecto, así que solo tienes que indicarlo una vez: + +```ts +import { Lizard } from '@lizard-build/sdk'; + +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +from lizard import Lizard + +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +`Sandbox.create` acepta la misma opción `project` cuando prefieres no mantener un cliente. A continuación se usan ambas formas. + + + +## Tu primer sandbox + +**JavaScript / TypeScript** + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +// Boot from a template (default: 'base') in a project +const sandbox = await Sandbox.create('base', { project: 'my-project' }); + +// Run a command and wait for it to finish +try { + const result = await sandbox.process.exec('node -e "console.log(2 ** 10)"'); + console.log(result.stdout); // 1024 + console.log(result.exitCode); // 0 +} finally { + await sandbox.kill(); +} +``` + +**Python** + +```python +from lizard import Sandbox + +sandbox = Sandbox.create("base", project="my-project") + +# exec_ (trailing underscore) because `exec` is reserved in Python +try: + result = sandbox.process.exec_("python -c 'print(2 ** 10)'") + print(result.stdout) # 1024 +finally: + sandbox.kill() +``` + +`process.exec` devuelve `{ stdout, stderr, exitCode }`. Espera a que el comando termine — envía procesos largos en segundo plano con un `&` final. + + + +## Trabajar con archivos + +`sandbox.fs` lee y escribe directamente en el sistema de archivos de la micro-VM, creando los directorios padre cuando hace falta. + +```ts +await sandbox.fs.write('/app/server.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('hello from Lizard')).listen(3000); +`); + +const src = await sandbox.fs.read('/app/server.js'); +const entries = await sandbox.fs.list('/app'); // [{ name, path, type, size }] +await sandbox.fs.makeDir('/app/data'); +await sandbox.fs.remove('/app/old.log'); +``` + +| Método | Descripción | +|---|---| +| `fs.write(path, data)` | Escribe un archivo — cadena o bytes; crea directorios padre | +| `fs.read(path)` | Lee un archivo como una cadena UTF-8 | +| `fs.list(path)` | Lista las entradas de un directorio | +| `fs.makeDir(path)` | Crea un directorio y los padres que falten | +| `fs.remove(path)` | Elimina un archivo o directorio | + + + +## Exponer un puerto + +Inicia un servidor HTTP dentro del sandbox y obtén una URL HTTPS pública para él — sin túneles. + +```ts +await sandbox.process.exec('node /app/server.js &'); // listen on :3000 + +const host = await sandbox.getHost(3000); +console.log(`Live at https://${host}`); +// https://-3000.sandbox..onlizard.com +``` + +`getHost(port)` registra una ruta para ese puerto y devuelve el nombre de host. La URL es pública y termina en TLS. Vuelve a eliminarla desde el panel. + + + +## Pausar y reanudar + +Pausar congela las vCPU invitadas y conserva su estado actual en la memoria del host. No escribe una instantánea persistente. Revisa el [problema de pausa y expiración](/platform/known-issues#sandbox-pause-and-expiration) antes de conservar una sesión más allá de su plazo original. + +```ts +// Set the environment up once +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +await sandbox.process.exec('npm install -g some-heavy-toolchain'); +const id = sandbox.sandboxId; + +await sandbox.pause(); // freeze the guest; see the lifecycle issue below + +// …minutes or hours later, from anywhere: +const resumed = await Sandbox.connect(id); // resumes guest state still held by the host +await resumed.process.exec('some-heavy-toolchain --version'); // already installed +await resumed.kill(); +``` + +`Sandbox.connect(id)` reanuda automáticamente un sandbox en pausa. También puedes llamar a `sandbox.resume()` sobre un identificador que ya tengas. + +**Python** + +```python +sandbox = Sandbox.create("base", project="my-project") +sandbox.process.exec_("pip install numpy pandas") +sandbox_id = sandbox.sandbox_id +sandbox.pause() + +resumed = Sandbox.connect(sandbox_id) # resumes guest state still held by the host +resumed.process.exec_("python -c 'import numpy'") +resumed.kill() +``` + + + +## Tiempos de espera + +Un sandbox con un tiempo de espera positivo expira al terminar ese tiempo de vida. El SDK usa por defecto cinco minutos; `timeoutMs: 0` al crearlo desactiva la expiración. Define un límite explícito y libera el sandbox cuando termine la tarea. Ajusta un sandbox en ejecución con: + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); // 10 min +await sandbox.setTimeout(30 * 60 * 1000); // extend to 30 min from now +``` + +La pausa está pensada para congelar el tiempo de ejecución restante, pero el actual [problema del ciclo de vida](/platform/known-issues#sandbox-pause-and-expiration) necesita una versión de backend verificada. No dependas de una pausa ilimitada para conservar datos. + + + +## Gestionar sandboxes + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const info = await sandbox.getInfo(); // { sandboxId, template, startedAt, endAt, … } + +const all = await Sandbox.list(); // every running sandbox for this account +await sandbox.kill(); +``` + + + +## Ejemplo completo + +Un agente que escribe un script, lo ejecuta, sirve el resultado y pone el invitado en pausa para una llamada posterior: + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 15 * 60 * 1000 }); + +try { + await sandbox.fs.write('/app/app.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('ok')).listen(3000); + `); + await sandbox.process.exec('node /app/app.js &'); + + const host = await sandbox.getHost(3000); + const res = await fetch(`https://${host}`); + console.log(await res.text()); // ok + + await sandbox.pause(); // resume later with Sandbox.connect(sandbox.sandboxId) +} catch (err) { + await sandbox.kill(); + throw err; +} +``` + + + +## Siguientes pasos + +- **[Referencia del SDK](/sandboxes/sdk-reference)** — todos los métodos de `Sandbox`, `CodeSandbox` y `Volume`. +- **[Intérprete de código](/sandboxes/code-interpreter)** — ejecuta código con estado y en varios lenguajes. +- **[Persistent Volumes](/sandboxes/volumes)** — adjunta almacenamiento que sobrevive a un solo sandbox. diff --git a/_locales/es/sandboxes/sdk-reference.mdx b/_locales/es/sandboxes/sdk-reference.mdx new file mode 100644 index 0000000..8ea12f4 --- /dev/null +++ b/_locales/es/sandboxes/sdk-reference.mdx @@ -0,0 +1,144 @@ +--- +description: "Todas las clases y métodos del Lizard SDK para JavaScript y Python: Lizard, Sandbox, CodeSandbox y Volumen, con opciones y tipos de retorno." +--- + + + +# Referencia del SDK + +Los paquetes `@lizard-build/sdk` (JS/TS) y `lizard-sdk` (Python) son los que usan la mayoría de agentes, apps y scripts para controlar sandboxes. Esta página cataloga cada clase y método; consulta la [Guía de inicio rápido](/sandboxes/quickstart) para ver un recorrido. + + + +## Instalar y autenticar + +```bash +npm install @lizard-build/sdk # JavaScript / TypeScript +pip install lizard-sdk # Python +``` + +El SDK lee `LIZARD_API_KEY` del entorno, o acepta una opción explícita `apiKey` en `Sandbox.create` / `Sandbox.connect`. Consulta [Guía de inicio rápido → Autenticar](/sandboxes/quickstart#authenticate) para ver cómo crear una clave. + +Cada sandbox también pertenece a un **proyecto**: el uso se mide por proyecto, así que se rechazará una creación sin uno. + +## `Lizard` + +Un cliente fijado a un proyecto, para que nombres el proyecto una vez en lugar de hacerlo en cada llamada. + +| Miembro | Descripción | +|---|---| +| `new Lizard({ project, apiKey?, apiUrl?, timeoutMs? })` | Crea un cliente. `project` es obligatorio: su ID, slug o nombre (`Lizard(project=…)` en Python). | +| `lizard.create(template?, options?)` | Inicia un sandbox en el proyecto del cliente. | +| `lizard.connect(sandboxId)` | Se conecta a un sandbox por ID, reanudándolo automáticamente si está en pausa. | +| `lizard.list()` | Lista todos los sandboxes en ejecución de la cuenta. | +| `lizard.projectId()` | Resuelve la referencia de proyecto del cliente a su ID (se almacena en caché después de la primera llamada). | + +```ts +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +Una referencia de proyecto que no coincide con nada a lo que la clave pueda acceder genera un error antes de iniciar cualquier sandbox, enumerando los proyectos que puede ver. + +> Los nombres de métodos de Python con un guion bajo final (`exec_`) evitan conflictos con palabras reservadas, y las propiedades usan snake_case (`sandbox_id`) en lugar de camelCase (`sandboxId`). Los ejemplos de abajo usan nombres de JS/TS; revisa el paquete de Python instalado para ver las firmas de los métodos. + +## `Sandbox` + +| Miembro | Descripción | +|---|---| +| `Sandbox.create(template?, options?)` | Inicia un sandbox. `template` usa por defecto `'base'`; `options.project` indica el proyecto al que se facturará. | +| `Sandbox.connect(sandboxId)` | Se conecta a un sandbox por ID, reanudándolo automáticamente si está en pausa. | +| `Sandbox.list()` | Lista todos los sandboxes en ejecución de la cuenta. | +| `sandbox.sandboxId` | El ID del sandbox (`sandbox_id` en Python). | +| `sandbox.process.exec(cmd)` | Ejecuta un comando y espera a que termine (`process.exec_` en Python). Devuelve `{ stdout, stderr, exitCode }`. | +| `sandbox.fs.write(path, data)` | Escribe un archivo, ya sea string o bytes; crea los directorios padre. | +| `sandbox.fs.read(path)` | Lee un archivo como string UTF-8. | +| `sandbox.fs.list(path)` | Lista las entradas del directorio → `[{ name, path, type, size }]`. | +| `sandbox.fs.makeDir(path)` | Crea un directorio y cualquier padre que falte. | +| `sandbox.fs.remove(path)` | Elimina un archivo o directorio. | +| `sandbox.getHost(port)` | Registra una ruta en `port` y devuelve su nombre de host público con terminación TLS. | +| `sandbox.pause()` | Detiene las vCPU invitadas y conserva el estado en la memoria del host. Consulta el [estado del ciclo de vida](#lifecycle-status) antes de depender de una pausa más allá del plazo original. | +| `sandbox.resume()` | Reanuda un sandbox en pausa en el mismo lugar. | +| `sandbox.setTimeout(ms)` | Establece la vida útil restante de un sandbox en ejecución en milisegundos (mínimo 1000). | +| `sandbox.getInfo()` | Obtiene metadatos → `{ sandboxId, template, startedAt, endAt, … }`. | +| `sandbox.kill()` | Termina el sandbox de inmediato y libera sus recursos. | + +### `Sandbox.create(template?, options?)` + +| Opción | Tipo | Predeterminado | Notas | +|---|---|---|---| +| `template` | string | `'base'` | `'base'` o `'code-interpreter-v1'`: las dos [plantillas](/sandboxes#templates) compatibles | +| `project` | string | — | **Obligatorio.** El proyecto al que se facturará: su ID, slug o nombre (`project` en Python). No hace falta con un cliente `Lizard`. | +| `projectId` | string | — | ID exacto del proyecto; omite la resolución de `project` | +| `timeoutMs` | int | valor predeterminado del SDK 5 min | Vida útil en ms | +| `region` | string | auto | Fijar en una región | +| `volumeId` | string | — | Adjunta un [volume](/sandboxes/volumes) en `/data` | +| `apiKey` | string | variable de entorno `LIZARD_API_KEY` | Clave de API explícita; anula el entorno | + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); +``` + +## `CodeSandbox` + +Amplía `Sandbox` con un kernel con estado. Consulta [Intérprete de código](/sandboxes/code-interpreter) para ver el recorrido completo. + +| Miembro | Descripción | +|---|---| +| `CodeSandbox.create(options?)` | Inicia un intérprete de código (usa por defecto la plantilla `code-interpreter-v1`). Acepta la misma opción `project` que `Sandbox.create`. | +| `CodeSandbox.connect(sandboxId)` | Se conecta a un sandbox existente de intérprete de código (y lo reanuda automáticamente). | +| `sandbox.runCode(code, opts?)` | Ejecuta código en el kernel. Devuelve un `Execution`. | +| `sandbox.createContext(opts)` | Crea un espacio de nombres aislado: `{ language }`. | +| `sandbox.listContexts()` | Lista los contextos del sandbox. | +| `sandbox.restartContext(context)` | Borra todas las variables y el estado de un contexto. | +| `sandbox.deleteContext(context)` | Libera los recursos de un contexto. | + +### `runCode(code, opts?)` + +| Opción | Descripción | +|---|---| +| `language` | Entorno de ejecución para una llamada puntual: `'python'` (predeterminado), `'javascript'` o `'bash'`. Excluyente con `context`. | +| `context` | Ejecuta dentro de un contexto aislado específico en lugar del predeterminado. Excluyente con `language`. | +| `onStdout` / `onStderr` | Transmite la salida línea por línea a medida que se produce. | +| `onResult` | Se llama para cada resultado enriquecido (valores, imágenes/gráficos generados). | +| `onError` | Se llama con un `ExecutionError` si el código lanza una excepción. | + +Devuelve un `Execution`: + +| Campo | Descripción | +|---|---| +| `stdout` / `stderr` | Flujos de salida capturados | +| `results` | Resultados enriquecidos (valores y cualquier imagen / gráfico generado) | +| `error` | Un `ExecutionError` (`name`, `message`, `traceback`) si el código lanzó una excepción | +| `executionCount` | Contador monotónico del kernel | + +## `Volume` + +Consulta [Persistent Volumes](/sandboxes/volumes) para ver el recorrido completo. + +| Miembro | Descripción | +|---|---| +| `Volume.create(projectId, name, options)` | Crea un volume. `options.sizeGb` usa por defecto `5`. | +| `Volume.list(projectId)` | Lista los volúmenes de un proyecto → `[{ id, name, sizeGb, status, attachedTo, … }]`. | +| `Volume.get(projectId, volumeId)` | Obtiene un identificador de un volume existente. | +| `volume.getInfo(projectId)` | Obtiene metadatos y el estado del adjunto. | +| `volume.delete(projectId)` | Elimina un volume: primero debe estar desacoplado. | + + + +## Ver también + +- [Guía de inicio rápido](/sandboxes/quickstart): instalación, autenticación y un recorrido completo. +- [Intérprete de código](/sandboxes/code-interpreter): la guía de `CodeSandbox`. +- [Persistent Volumes](/sandboxes/volumes): la guía de `Volume`. + + + +## Estado del ciclo de vida + +Antes de depender de la pausa para conservar una sesión más allá de su plazo original, consulta los [problemas conocidos](/platform/known-issues#sandbox-pause-and-expiration). La pausa mantiene el estado invitado en la memoria del host; no es una copia de seguridad duradera. diff --git a/_locales/es/sandboxes/volumes.mdx b/_locales/es/sandboxes/volumes.mdx new file mode 100644 index 0000000..3c0b6fc --- /dev/null +++ b/_locales/es/sandboxes/volumes.mdx @@ -0,0 +1,79 @@ +--- +description: "Adjunta un volumen en /data para conservar checkpoints, weights o un directorio de trabajo entre reinicios del sandbox. Crea, adjunta y administra volúmenes." +--- + +# Persistent Volumes + +Los Sandboxes son efímeros: cuando uno se elimina o expira, su sistema de archivos desaparece. Un **volumen** es almacenamiento persistente por bloques que sobrevive a cualquier sandbox individual. Adjunta uno para conservar datos (checkpoints, pesos del modelo, un directorio de trabajo) entre reinicios del sandbox. + +Un volumen se adjunta a **un sandbox a la vez** y se monta en **`/data`** dentro de la micro-VM. Como un volumen queda fijado al nodo en el que reside, un sandbox que lo adjunta se programa en ese mismo nodo. + + + +## Crear y adjuntar + +Adjunta un volumen pasando su ID a `Sandbox.create`, junto con el proyecto al que se factura el sandbox. Todo lo que se escriba en `/data` se conserva después de que el sandbox desaparezca. + +```ts +import { Sandbox, Volume } from '@lizard-build/sdk'; + +// Create a 10 GB volume in a project (default size: 5 GB) +const volume = await Volume.create('proj_123', 'agent-workdir', { sizeGb: 10 }); + +// Attach it to a sandbox — mounted at /data +const sandbox = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + await sandbox.fs.write('/data/state.json', JSON.stringify({ step: 1 })); +} finally { + await sandbox.kill(); // the volume persists +} + +// A later sandbox re-attaches and sees the data +const next = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + console.log(await next.fs.read('/data/state.json')); // {"step":1} +} finally { + await next.kill(); +} +``` + + + +## Administrar volúmenes + +```ts +await Volume.list('proj_123'); // [{ id, name, sizeGb, status, attachedTo, … }] +const v = await Volume.get('proj_123', 'vol_abc'); +await v.getInfo('proj_123'); +await v.delete('proj_123'); // must be detached first +``` + +| Método | Descripción | +|---|---| +| `Volume.create(projectId, name, { sizeGb })` | Crear un volumen (5 GB por defecto) | +| `Volume.list(projectId)` | Listar volúmenes en un proyecto | +| `Volume.get(projectId, volumeId)` | Obtener un identificador de un volumen existente | +| `volume.getInfo(projectId)` | Obtener metadatos y estado de adjunto | +| `volume.delete(projectId)` | Eliminar un volumen (debe no estar adjunto) | + + + +## En el dashboard + +Los volúmenes se encuentran en la pestaña **Sandboxes → Volúmenes** de un proyecto. Crea uno con un nombre y un tamaño; la tabla muestra el tamaño de cada volumen, su estado (`available` / `attached`) y qué sandbox lo tiene adjunto. Un volumen se libera de vuelta a `available` automáticamente cuando su sandbox se elimina o expira. Consulta la guía de [Panel](/sandboxes/dashboard). + + + +## Notas + +- Un volumen solo puede adjuntarse a **un sandbox** a la vez. Intentar adjuntar un volumen que ya está adjunto devuelve un conflicto. +- Eliminar un sandbox (o dejar que expire) **desadjunta** el volumen; no lo elimina. Los datos se conservan para el siguiente adjunto. +- Elimina el propio volumen para recuperar el almacenamiento. +- Un sandbox en pausa sigue manteniendo su adjunto. Persistent Volumes usan almacenamiento local al nodo; exporta los datos que necesites recuperar tras una falla del nodo. Consulta [almacenamiento y recuperación](/platform/storage-and-recovery). + + + +## Ver también + +- [SDK Reference](/sandboxes/sdk-reference) — todos los métodos de `Volume`. +- [Quickstart](/sandboxes/quickstart) — adjuntar un volumen al crear un sandbox. diff --git a/_locales/es/studio/_meta.ts b/_locales/es/studio/_meta.ts new file mode 100644 index 0000000..e7e4623 --- /dev/null +++ b/_locales/es/studio/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'getting-started': "Instalar Lizard Studio", +}; diff --git a/_locales/es/studio/getting-started.mdx b/_locales/es/studio/getting-started.mdx new file mode 100644 index 0000000..2d0a292 --- /dev/null +++ b/_locales/es/studio/getting-started.mdx @@ -0,0 +1,145 @@ +--- +title: "Instala Lizard Studio para Claude Code y ChatGPT" +description: "Instala Lizard Studio en Chrome, conecta Claude Code o ChatGPT a un proyecto local y haz tu primera edición de sitio web. Sigue la guía de configuración." +--- + + + +# Instala Lizard Studio + +Lizard Studio es una extensión gratuita de Chrome que conecta Claude Code o ChatGPT con la página que estás construyendo. Abre un chat junto a la página, selecciona un elemento y pídele al agente que edite los archivos de tu proyecto local. La extensión incluye inspección de páginas, anotaciones, reglas, un selector de color y herramientas de depuración del navegador. + +Esta guía te lleva desde la instalación hasta una edición de código fuente que sobrevive a una actualización de la página. Para ver un ejemplo que puedes descargar, consulta [la guía de edición visual de Claude Code](https://lizard.build/blog/claude-code-visual-editor). + + + +## Lo que necesitas + +- Google Chrome en macOS, Windows o Linux. +- Node.js y npm. El host local declara Node.js 18 o posterior; el agente que elijas puede tener un requisito superior. Usa una versión de Node.js compatible con ambos. +- La CLI local de Claude Code o ChatGPT, con sesión iniciada en tu propia cuenta. +- Una carpeta de proyecto local. Para ver las ediciones de código fuente en el navegador, ejecuta el servidor de desarrollo de ese proyecto y abre su URL. + +La extensión y el host son gratuitos y tienen licencia MIT. El uso del modelo sigue los requisitos, límites y cargos de la cuenta de tu proveedor. No necesitas una cuenta de Lizard para usar Lizard Studio. + + + +## 1. Añade la extensión de Chrome + +Abre [Lizard Studio en Chrome Web Store](https://chromewebstore.google.com/detail/kgbaeoalmkabpoglpjcdmppdmcipfdeh) y elige **Add to Chrome**. Fija la extensión si quieres acceder a ella desde la barra de herramientas. + +La barra de herramientas ofrece las herramientas de diseño; el panel lateral de Chrome contiene tus chats. La instalación desde la tienda no requiere el modo de desarrollador. + + + +## 2. Instala tu agente + +Elige el agente que quieres usar. Puedes añadir el otro más tarde. + +Para Claude Code, sigue la [guía oficial de configuración](https://code.claude.com/docs/en/setup). Comprueba la instalación en una terminal: + +```bash +claude --version +``` + +Para ChatGPT en Lizard Studio, instala la Codex CLI: + +```bash +npm install -g @openai/codex +codex --version +``` + +Lizard Studio llama a este agente **ChatGPT** en su interfaz. El paquete y el comando de terminal usan el nombre **Codex**. Este es un agente de programación local conectado a tu proyecto; no integra el sitio web chatgpt.com. + +Abre el agente que hayas elegido y completa su flujo de inicio de sesión antes de continuar. Consulta [el README de Lizard Studio](https://github.com/lizard-build/lizard-studio#setup) para ver las rutas de conexión compatibles. + + + +## 3. Instala el host local + +Ejecuta este comando una vez en una terminal: + +```bash +npx @lizard-build/lizard-studio-host install +``` + +El host conecta la extensión de Chrome con el agente en tu equipo. El instalador copia el host en `~/.lizard-studio/host` y lo registra en el navegador. Mantén Node.js instalado: el navegador lo usa para iniciar el host. + +Vuelve a abrir el panel lateral de la extensión después de la instalación. Si actualizaste un host existente, vuelve a abrir el panel antes de iniciar un chat nuevo. + + + +## 4. Conecta la página con su proyecto + +Inicia el servidor de desarrollo de tu proyecto con su comando habitual. Abre en Chrome la URL que muestre y luego abre Lizard Studio en esa pestaña. + +Inicia un chat, elige **Claude Code** o **ChatGPT**, y elige la carpeta que contiene el código fuente de este proyecto. Cada chat mantiene su propia carpeta de proyecto y permisos. Una pestaña que muestra la página correcta no le indica por sí sola al agente qué repositorio local debe cambiar. + +Antes de pedir una edición, comprueba la conexión con una solicitud de solo lectura: + +```text +Read this page's title and inspect its main heading. Tell me which +local project folder you are using. Do not change any files yet. +``` + +Si el agente nombra la carpeta equivocada, corrige la selección antes de continuar. + + + +## 5. Selecciona un elemento y haz una edición + +Elige **Selector** en la barra de herramientas de la página y haz clic en el elemento que quieres cambiar. La selección añade contexto al chat. Para un problema visual que abarca varios elementos, usa **Annotate** para marcar el área y añadir la captura de pantalla al chat. + +Prueba una solicitud con un resultado medible: + +```text +Find the source for the selected card's action row. Set the gap +between its buttons to 24px in the project files. Keep the button +labels and colors unchanged. Show the diff, then inspect the +rendered row to check its computed gap. +``` + +Lee los cambios de archivo propuestos y usa los controles de permisos para aprobar el trabajo que quieras. Tu modo de permisos determina qué acciones necesitan una solicitud independiente. + +Cuando el servidor de desarrollo vuelva a cargar la página, inspecciona el resultado. Si no se recarga automáticamente, actualiza Chrome. + + + +## 6. Comprueba que la edición persiste + +Una edición temporal del DOM puede verse correcta hasta que actualices. Una edición del código fuente cambia los archivos que sirve tu servidor de desarrollo. + +Comprueba el diff del archivo en tu editor o ejecuta `git diff` desde la carpeta del proyecto. Actualiza la página e inspecciona de nuevo el mismo elemento. En el ejemplo anterior, su gap calculado debería seguir siendo `24px`. Revisa tanto la versión de escritorio como los diseños estrechos antes de conservar el cambio. + +Editar un proyecto local no actualiza un sitio web desplegado. Haz el despliegue por separado cuando quieras que el cambio entre en producción. + + + +## Si la conexión falla + +| Lo que ves | Qué comprobar | +|---|---| +| El panel lateral no puede conectarse con el host | Ejecuta el instalador del host, confirma que Node.js está disponible y luego vuelve a abrir el panel. | +| El agente no puede iniciarse | Comprueba `claude --version` o `codex --version` en una terminal y completa el inicio de sesión de ese agente. | +| El agente ve la página pero no puede encontrar su código | Elige la carpeta local correcta y confirma que la pestaña usa el servidor de desarrollo de ese proyecto. | +| Una edición desaparece al actualizar | Comprueba el diff. Pide un cambio en el código fuente si el agente solo cambió el DOM en vivo. | +| La barra de herramientas no aparece en una página de configuración de Chrome | Chrome bloquea los scripts de contenido en páginas `chrome://`, en la página Nueva pestaña y en Chrome Web Store. Abre un sitio web normal. | + +En macOS, la ubicación del host en `~/.lizard-studio/host` también evita las restricciones que Chrome puede encontrar al iniciar un host dentro de Desktop, Documents o Downloads. Consulta [las notas del host en el README](https://github.com/lizard-build/lizard-studio#2-the-local-host-one-time) para más detalles. + + + +## Adónde van tus datos + +La extensión y el host se ejecutan en tu equipo. El proveedor del modelo seleccionado recibe las solicitudes que envías a través de su agente. Lizard Studio no usa un servidor de chat de Lizard ni recopila telemetría. Una instalación local no significa que un modelo en la nube procese tus prompts de forma local. Lee la [política de privacidad de Lizard Studio](https://github.com/lizard-build/lizard-studio/blob/main/PRIVACY.md) antes de usarlo con un proyecto que tenga restricciones de datos. + + + +## Guías relacionadas + +- [Selecciona un elemento y corrige su CSS](https://lizard.build/blog/claude-code-visual-editor) +- [Usa ChatGPT para editar un sitio web local](https://lizard.build/studio/chatgpt) +- [Compara Lizard Studio y Claude en Chrome](https://lizard.build/studio/compare/claude-in-chrome) +- [Elige una GUI para Claude Code](https://lizard.build/blog/claude-code-gui) + +Configuración verificada con el código fuente de Lizard Studio el 14 de septiembre de 2026. diff --git a/_locales/es/variables/_meta.ts b/_locales/es/variables/_meta.ts new file mode 100644 index 0000000..7b1d1e8 --- /dev/null +++ b/_locales/es/variables/_meta.ts @@ -0,0 +1,5 @@ +export default { + index: "Variables y secretos", + references: "Referencias entre servicios", + troubleshooting: "Solución de problemas", +}; diff --git a/_locales/es/variables/index.mdx b/_locales/es/variables/index.mdx new file mode 100644 index 0000000..c39d8b0 --- /dev/null +++ b/_locales/es/variables/index.mdx @@ -0,0 +1,112 @@ +--- +description: "Configura secrets con alcance de servicio o de proyecto, conoce la precedencia de combinación y ve qué valores llegan a una compilación frente al contenedor en ejecución." +--- + + + +# Variables y secrets + +Lizard almacena la configuración como **secrets**. Vienen en dos alcances: **servicio** (el predeterminado) y **proyecto** (`--global`), y se combinan en el entorno de tu app con un orden de precedencia definido. No hay un alcance global a nivel de workspace. + + + +## Configurar variables + +`lizard secrets set` es variádico: configura una o varias a la vez. De forma predeterminada escribe en el **servicio vinculado**: + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + +Añade `--global` para escribir en el alcance de **proyecto** (todos los servicios del proyecto lo verán): + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +## Listar, eliminar, importar + +```bash +lizard secrets list # current scope +lizard secrets list --show # reveal values +lizard secrets delete OLD_KEY ANOTHER_KEY # variadic +cat .env | lizard secrets import # import dotenv from stdin +``` + +Consulta la [referencia de comandos de `lizard secrets`](/cli/secrets) para ver todas las opciones. + + + +## Alcances + +| Ámbito | Comando | Almacenado como | Visible para | +|-------|---------|-----------|------------| +| **Servicio** (predeterminado) | `lizard secrets set K=v --service ` | `secrets.services[]` | solo ese servicio | +| **Proyecto** (global) | `lizard secrets set K=v --global` | `secrets.shared` | todos los servicios del proyecto | + +**Usa por defecto el alcance de servicio.** Un servicio comprometido puede leer su propio entorno; un alcance más amplio significa más credenciales expuestas sin necesidad. Reserva `--global` para valores no secretos y demostrablemente públicos como `LOG_LEVEL`, `NODE_ENV`, feature flags o un frontend `SENTRY_DSN`. Si no estás seguro de si un valor es un secret, trátalo como tal y asígnalo al servicio. + +Para recursos compartidos como una base de datos, **no** pongas el DSN en `--global`; vincúlalo por consumidor con una [referencia](/variables/references): + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service worker +``` + +La rotación sigue ocurriendo una sola vez en el addon; todas las referencias se actualizan. + + + +## Precedencia + +Cuando la misma clave se define en varios lugares, **la última escritura prevalece**: + +``` +addon-issued env < project secrets < project env < app env < app secrets < platform vars +``` + +Así que **los secrets de la app anulan los secrets del proyecto**, y **las variables de la plataforma** (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) se aplican al final y no se pueden sobrescribir. + + + +## Tiempo de compilación vs. tiempo de ejecución + +La mayoría de los cambios de variables se aplican **sin recompilar**: el servicio se reinicia para recogerlos, lo que tarda unos segundos. Las excepciones son los valores de compilación integrados en la imagen: + +- Los cambios en `VITE_*` y `NEXT_PUBLIC_*` **fuerzan una recompilación** en el siguiente deploy. + +Consulta [Pipeline de compilación → desencadenantes de recompilación](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Verificación + +Confirma qué ve realmente un servicio en ejecución: + +```bash +lizard ssh --service api -- env +``` + +Si un valor que esperabas no está ahí, consulta [Resolución de problemas → un secret o una referencia no aparece](/variables/troubleshooting/reference-not-applied). + + + +## Desarrollo local + +Ejecuta un comando **localmente** con los secrets de proyecto + servicio del servicio inyectados (útil para scripts y migraciones): + +```bash +lizard run --service api -- node scripts/seed.js +``` + +Consulta [`lizard run` vs. `lizard ssh`](/cli/run#run-vs-ssh). + + + +## Ver también + +- [Referencias entre servicios](/variables/references): lee los valores de un servicio desde otro sin copiar y pegar credenciales. +- [`lizard secrets`](/cli/secrets): la referencia completa de comandos. diff --git a/_locales/es/variables/references.mdx b/_locales/es/variables/references.mdx new file mode 100644 index 0000000..1ad1e52 --- /dev/null +++ b/_locales/es/variables/references.mdx @@ -0,0 +1,78 @@ +--- +description: "Lee los valores de un servicio o addon desde otro con la sintaxis ${{name.KEY}}. Cómo se resuelven las referencias en el momento del despliegue y por qué son mejores que copiar." +--- + + + +# Referencias entre servicios + +Las referencias permiten que un servicio o addon lea los valores de otro sin copiar y pegar credenciales. Mantienen los secretos en un solo lugar y rotan automáticamente. + + + +## Sintaxis + +``` +${{.}} +``` + +- `` — el nombre del servicio o addon de destino (el que se muestra en el dashboard y se usa en `lizard add -n`). +- `` — una clave en el entorno combinado del destino. + +Úsalas en cualquier lugar donde se acepte un valor; lo más habitual es en un secreto: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + + + +## Cómo se resuelven + +- Las referencias se resuelven en el **momento del despliegue** usando el entorno combinado del destino. +- Se almacenan por **ID**, así que cambiar el nombre del destino más adelante no rompe la referencia. +- Una referencia a un destino o clave **inexistente** se resuelve como una **cadena vacía**: *no* hace fallar el despliegue. +- Solo las referencias **circulares** producen un error. + +> Como una clave faltante pasa silenciosamente a estar vacía, verifica siempre que el consumidor realmente haya recibido el valor después de conectar una referencia: +> ```bash +> lizard ssh --service api -- env | grep DATABASE_URL +> ``` + +Si una referencia no aparece como esperas, consulta [Solución de problemas → no aparece un secreto o referencia](/variables/troubleshooting/reference-not-applied). + + + +## Patrones habituales + +**Conecta un addon a varios servicios**: vincúlalo en cada consumidor para que la rotación se propague a todas partes: + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +``` + +**Haz referencia al valor de otro servicio**: por ejemplo, comparte una URL calculada o un token: + +```bash +lizard secrets set UPSTREAM_URL='${{api.LIZARD_PUBLIC_DOMAIN}}' --service web +``` + +**Haz referencia a un segundo addon del mismo tipo**: usa su nombre generado: + +```bash +lizard secrets set CACHE_URL='${{redis-winter-otter.REDIS_URL}}' --service api +``` + + + +## ¿Por qué no usar simplemente `--global`? + +Poner un DSN compartido en el ámbito del proyecto (`--global`) lo expone a *todos* los servicios, incluidos los que no lo necesitan. Las referencias te dan la misma rotación con una sola fuente de verdad, pero mantienen cada secreto limitado a los servicios que realmente lo consumen. Consulta [Alcance de secretos](/variables#scoping). + + + +## Ver también + +- [Variables y secretos](/variables) — ámbitos y precedencia. +- [`lizard secrets`](/cli/secrets) — la referencia completa de comandos. diff --git a/_locales/es/variables/troubleshooting/_meta.ts b/_locales/es/variables/troubleshooting/_meta.ts new file mode 100644 index 0000000..9df551e --- /dev/null +++ b/_locales/es/variables/troubleshooting/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'reference-not-applied': "Un secreto o una referencia no aparece", +}; diff --git a/_locales/es/variables/troubleshooting/reference-not-applied.mdx b/_locales/es/variables/troubleshooting/reference-not-applied.mdx new file mode 100644 index 0000000..3100ef7 --- /dev/null +++ b/_locales/es/variables/troubleshooting/reference-not-applied.mdx @@ -0,0 +1,71 @@ +--- +description: "Tu secreto o referencia está configurado, pero el servicio nunca lo ve. Los destinos que faltan se resuelven como cadenas vacías, y la precedencia puede ocultar un valor." +--- + + + +# Un secreto o una referencia no aparece en mi servicio + +Configuraste un secreto o una referencia `${{name.KEY}}`, volviste a desplegar y el servicio en ejecución sigue sin ver el valor que esperas. + + + +## Qué significa esto + +El valor que configuraste nunca llegó al entorno combinado del servicio, o algo más en la combinación lo sobrescribió antes de que la app se iniciara. + + + +## Por qué puede pasar esto + +- **El destino o la clave de la referencia no existen.** Una referencia a un nombre de servicio/addon que no existe, o a una clave que ese addon no expone, se resuelve como una **cadena vacía** en lugar de hacer fallar el despliegue. No hay ningún error que te avise: el servicio simplemente arranca con un valor vacío. +- **Algo con mayor precedencia lo sobrescribió.** Los valores se combinan en un orden fijo — `addon-issued env < project secrets < project env < app env < app secrets < platform vars` — así que un secreto con alcance de proyecto (`--global`) puede quedar oculto silenciosamente por uno con alcance de servicio con la misma clave, y las variables de la plataforma (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) siempre prevalecen y no se pueden sobrescribir en absoluto. +- **Cambiaste un valor de tiempo de compilación pero no recompilaste.** La mayoría de los cambios de variables se aplican sin recompilar: el servicio se reinicia para tomarlos. Los valores de `VITE_*` y `NEXT_PUBLIC_*` son la excepción: quedan integrados en los recursos compilados, así que un reinicio normal no aplicará un valor nuevo; el servicio necesita una compilación nueva. + + + +## Posibles soluciones + + + +### Confirma lo que realmente ve el servicio en ejecución + +Esto es determinante: muestra el entorno del contenedor activo, no lo que crees haber configurado: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + +Si la clave falta o está vacía, el destino/clave de la referencia es incorrecto, o no hay nada configurado para ese alcance. Vuelve a comprobar el nombre del addon o servicio con `lizard ps`, y la clave en las [variables documentadas](/addons) del addon. + + + +### Comprueba si hay una colisión de alcance + +Enumera los secretos en ambos alcances y compáralos: + +```bash +lizard secrets list --service api --show +lizard secrets list --global --show +``` + +Recuerda que **los secretos de la app sobrescriben los secretos del proyecto**: si existe un valor con alcance de servicio para la misma clave, prevalece sobre cualquier cosa configurada con `--global`. + + + +### Recompila después de un cambio en tiempo de compilación + +Si la clave modificada es `VITE_*` o `NEXT_PUBLIC_*`, activa una recompilación real en lugar de un reinicio: + +```bash +lizard redeploy --service api +``` + +Consulta [Tiempo de compilación vs. tiempo de ejecución](/variables#build-time-vs-runtime) y [Proceso de compilación → qué activa una recompilación](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Ver también + +- [Variables y secretos](/variables) — alcance y precedencia. +- [Referencias entre servicios](/variables/references) — sintaxis de referencia y resolución. diff --git a/_locales/ja/_meta.ts b/_locales/ja/_meta.ts new file mode 100644 index 0000000..f477186 --- /dev/null +++ b/_locales/ja/_meta.ts @@ -0,0 +1,18 @@ +export default { + index: "はじめに", + 'getting-started': "アプリ クイックスタート", + studio: "Lizard Studio", + 'framework-guides': "フレームワーク ガイド", + guides: "ガイド", + platform: "制限と運用", + concepts: "コアコンセプト", + deploy: "デプロイ", + variables: "変数", + networking: "ネットワーキング", + addons: "Managed Addons", + sandboxes: "Sandboxes", + observability: "オブザーバビリティ", + cli: "CLI リファレンス", + dashboard: "アプリ ダッシュボード", + agents: "コーディングエージェント", +}; diff --git a/_locales/ja/addons/_meta.ts b/_locales/ja/addons/_meta.ts new file mode 100644 index 0000000..3aa29ce --- /dev/null +++ b/_locales/ja/addons/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "概要", + postgres: "Postgres", + redis: "Redis", + storage: "Object Storage (S3)", +}; diff --git a/_locales/ja/addons/index.mdx b/_locales/ja/addons/index.mdx new file mode 100644 index 0000000..c5dab08 --- /dev/null +++ b/_locales/ja/addons/index.mdx @@ -0,0 +1,80 @@ +--- +description: "1 つの lizard add コマンドでマネージド Postgres、Redis、S3 互換ストレージをプロビジョニングし、その後参照によってサービスに接続します。" +--- + + + +# マネージドアドオン + +Lizard は、単一のコマンドでマネージド **Postgres**、**Redis**、**S3 互換オブジェクトストレージ** をプロビジョニングします。各アドオンはプロジェクト内に作成され、固定の環境変数セットを公開し、サービスから [参照](/concepts/architecture#cross-resource-references) を通じて利用されます。 + + + +## アドオンをプロビジョニングする + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +## 命名 + +特定の種類の **最初の** アドオンは、その種類そのものを名前として受け取ります。つまり、`${{postgres.DATABASE_URL}}` はそのまますぐに動作します。同じ種類の追加アドオンには、`postgres-autumn-bear` のような生成された名前が付きます。 + +種類エイリアスへのフォールバックはありません。参照では、アドオンの **実際の** 名前を使う必要があります。参照は ID で保存されるため、後からアドオン名を変更しても、既存の利用側は壊れません: + +```bash +lizard service rename --service postgres # addons rename through the same command +``` + + + +## アドオンを利用する + +任意のサービスからアドオンの変数を参照できます。参照はデプロイ時に解決され、アドオンの認証情報が変更されると自動的にローテーションされます: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +参照は、実際にそれを使うサービスにだけスコープしてください（[Secret scoping](/variables#scoping) を参照）。 + + + +## 種類ごとの変数 + +| アドオン | 変数 | +|-------|-----------| +| **postgres** | `DATABASE_URL`, `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`, `POSTGRES_USER`, `POSTGRES_DB`, `POSTGRES_PASSWORD` | +| **redis** | `REDIS_URL` | +| **s3** | `S3_ENDPOINT`, `S3_DEFAULT_BUCKET`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `S3_REGION` | + + + +## ダッシュボードブラウザー + +[dashboard](/dashboard) には各アドオン用のデータブラウザーが用意されています。Postgres には SQL/テーブルエディター、Redis にはキーブラウザー、S3 にはバケット/オブジェクトブラウザーがあり、Lizard を離れずにデータを確認して編集できます。 + + + +## ストレージ + +アドオンのデータボリュームは **増加専用** です。容量の増加は次のコマンドで行います: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## 種類別ガイド + +- [Postgres](/addons/postgres) +- [Redis](/addons/redis) +- [Object Storage (S3)](/addons/storage) + +プロトタイプで通常この 3 つが一度に必要になる理由については、[SaaS に必要なスタックの残り](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#the-rest-of-the-stack-a-saas-needs) を参照してください。 diff --git a/_locales/ja/addons/postgres.mdx b/_locales/ja/addons/postgres.mdx new file mode 100644 index 0000000..8d4d0cb --- /dev/null +++ b/_locales/ja/addons/postgres.mdx @@ -0,0 +1,107 @@ +--- +description: "Lizard でマネージド PostgreSQL データベースをプロビジョニングし、参照でサービスに接続し、デプロイ時にマイグレーションを実行し、ストレージを拡張します。" +--- + +# Managed Postgres + +1 つのコマンドでプロビジョニングされ、参照によってサービスに接続されるマネージド PostgreSQL データベースです。 + + + +## プロビジョニング + +```bash +lizard add postgres +``` + +最初の Postgres アドオンの名前は `postgres` なので、`${{postgres.DATABASE_URL}}` はすぐに使えます。 + + + +## 環境変数 + +このアドオンは、標準的な接続変数一式を公開します: + +| 変数 | 説明 | +|----------|-------------| +| `DATABASE_URL` | 完全な接続文字列 (`postgres://…`) | +| `PGHOST` | ホスト | +| `PGPORT` | ポート | +| `PGUSER` | ユーザー | +| `PGPASSWORD` | パスワード | +| `PGDATABASE` | データベース名 | +| `POSTGRES_USER` | ユーザーのエイリアス | +| `POSTGRES_DB` | データベースのエイリアス | +| `POSTGRES_PASSWORD` | パスワードのエイリアス | + + + +## サービスを接続 + +コンシューマーサービスから接続文字列を参照し、再デプロイします: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +参照はデプロイ時に解決され、アドオンの認証情報が変更された場合は自動的にローテーションされます。すべてのコンシューマーは次回のデプロイ時に新しい値を取得します。 + +接続文字列を表示せずに接続性を確認します: + +```bash +lizard run --service api -- sh -c 'psql "$DATABASE_URL" -c "SELECT 1"' +``` + + + +## デプロイ時にマイグレーションを実行 + +マイグレーションには pre-deploy コマンドを使用します。マイグレーションは安全に再試行でき、古いアプリケーション バージョンと新しいアプリケーション バージョンの両方に互換性があるようにしてください: + +```bash +lizard service set api --set preDeployCommand="npm run migrate" +lizard redeploy --service api +``` + +Django アプリの場合、コマンドは `python manage.py migrate` です。[Pythonアプリホスティング](https://lizard.build/blog/python-app-hosting#deploying-django) には Flask と FastAPI で同等の方法があります。 + + + +## データの参照とクエリ + +ダッシュボードの **Postgres editor** (`lizard open`) を開いて、SQL を実行し、テーブルを直接参照できます。一時的なローカル作業には、サービスに注入された環境でコマンドを実行します: + +```bash +lizard run --service api -- sh -c 'exec psql "$DATABASE_URL"' +``` + + + +## ストレージを拡張 + +データボリュームは拡張のみ可能です: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## 複数のデータベース + +2 つ目の Postgres を追加すると、自動生成された名前が付きます（例: `postgres-autumn-bear`）。明示的に参照してください: + +```bash +lizard add postgres +lizard secrets set ANALYTICS_URL='${{postgres-autumn-bear.DATABASE_URL}}' --service api +``` + + + +## 関連項目 + +- [Managed Addons](/addons) — 命名、参照、ダッシュボードのブラウザー。 +- [サービス間参照](/variables/references) — 参照構文と解決方法。 + +バックアップとリストアの計画については、[ストレージとリカバリ](/platform/storage-and-recovery) を参照してください。ローカルの `lizard run` には `psql` と到達可能なデータベース エンドポイントが必要です。これはデプロイされたサービス内では実行されません。 diff --git a/_locales/ja/addons/redis.mdx b/_locales/ja/addons/redis.mdx new file mode 100644 index 0000000..352da47 --- /dev/null +++ b/_locales/ja/addons/redis.mdx @@ -0,0 +1,79 @@ +--- +description: "キャッシュ、キュー、レート制限、pub/sub のために Managed Redis インスタンスを追加し、単一の参照でサービスに接続します。" +--- + +# Managed Redis + +キャッシュ、キュー、レート制限、pub/sub のためのマネージド Redis インスタンスです。 + + + +## プロビジョニング + +```bash +lizard add redis +``` + +最初の Redis アドオンの名前は `redis` なので、`${{redis.REDIS_URL}}` はすぐに使えます。 + + + +## 環境変数 + +| 変数 | 説明 | +|----------|-------------| +| `REDIS_URL` | 完全な接続文字列 (`redis://…`) | + + + +## サービスを接続する + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard redeploy --service api +``` + +参照はデプロイ時に解決され、アドオンの認証情報に合わせてローテーションされます。 + + + +## 一般的な用途 + +- **キャッシュ** — リクエストをキーにして計算結果を保存します。 +- **キュー / ワーカー** — Redis を、ジョブを消費する [workerモードのサービス](/deploy/workers) と組み合わせます。 +- **レート制限 / セッション** — [replicas](/deploy/scaling) 間で高速に共有状態を扱います。 + +```bash +# A worker that drains a Redis queue +lizard add -r your-org/worker -n jobs +lizard service set jobs --set containerPort=0 +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service jobs +lizard redeploy --service jobs +``` + + + +## キーを参照する + +ダッシュボードの **Redis browser** (`lizard open`) を開いて、キーと値を確認します。ローカルからアクセスするには: + +```bash +lizard run --service api -- sh -c 'exec redis-cli -u "$REDIS_URL"' +``` + + + +## ストレージを拡張する + +```bash +lizard scale --service redis --storage 4096 +``` + + + +## 関連項目 + +- [Managed Addons](/addons) — 命名、参照、ダッシュボードブラウザーについて。 +- [Background Workers](/deploy/workers) — Redis とキューを消費するワーカーの組み合わせについて。 + +`lizard run` は、選択したサービス環境でローカルにコマンドを開始します。`redis-cli` をローカルにインストールし、エンドポイントに到達可能であることを確認してください。 diff --git a/_locales/ja/addons/storage.mdx b/_locales/ja/addons/storage.mdx new file mode 100644 index 0000000..40722a2 --- /dev/null +++ b/_locales/ja/addons/storage.mdx @@ -0,0 +1,108 @@ +--- +description: "アップロード、アセット、バックアップ向けの S3互換オブジェクトストレージ。one lizard add s3 だけで public-read バケットと接続変数を取得できます。" +--- + +# Object Storage (S3) + +アップロード、アセット、バックアップ向けの S3互換オブジェクトストレージです。`s3` アドオンをプロビジョニングすると、**`default` という名前の public-read バケット** も作成されるため、追加設定なしでファイルを配信できます。 + + + +## プロビジョニング + +```bash +lizard add s3 +``` + +最初の S3 アドオンの名前は `s3` なので、`${{s3.S3_ENDPOINT}}` などもすぐに使えます。 + + + +## 環境変数 + +| 変数 | 説明 | +|----------|-------------| +| `S3_ENDPOINT` | S3互換エンドポイント URL | +| `S3_DEFAULT_BUCKET` | 自動作成されるバケット名 (`default`) | +| `S3_ACCESS_KEY_ID` | アクセスキー | +| `S3_SECRET_ACCESS_KEY` | シークレットキー | +| `S3_REGION` | リージョン | + + + +## サービスを接続 + +```bash +lizard secrets set \ + S3_ENDPOINT='${{s3.S3_ENDPOINT}}' \ + S3_DEFAULT_BUCKET='${{s3.S3_DEFAULT_BUCKET}}' \ + S3_ACCESS_KEY_ID='${{s3.S3_ACCESS_KEY_ID}}' \ + S3_SECRET_ACCESS_KEY='${{s3.S3_SECRET_ACCESS_KEY}}' \ + S3_REGION='${{s3.S3_REGION}}' \ + --service api +lizard redeploy --service api +``` + + + +## AWS SDKを使用する + +エンドポイントは S3互換です。**path-style** アドレッシングを設定してください: + +```ts +import { S3Client } from "@aws-sdk/client-s3"; + +const s3 = new S3Client({ + endpoint: process.env.S3_ENDPOINT, + region: process.env.S3_REGION, + forcePathStyle: true, // required + credentials: { + accessKeyId: process.env.S3_ACCESS_KEY_ID!, + secretAccessKey: process.env.S3_SECRET_ACCESS_KEY!, + }, +}); +``` + + + +## 公開ファイル + +任意の **public** バケット内のオブジェクトは、認証なしで次の 2 つの方法で配信されます: + +1. **Gateway URL** (ダッシュボードに表示): + ``` + https://s3-.onlizard.com/// + ``` +2. **Platform proxy** (ダッシュボードのホスト。長期間有効な immutable キャッシュヘッダー付き): + ``` + /api/s3//public// + ``` + +`default` バケットにアップロードされたものはすべて、すぐに次の URL で公開されます: + +``` +/api/s3//public/default/ +``` + + + +## オブジェクトの参照 + +ダッシュボードで **S3 browser** (`lizard open`) を開くと、オブジェクトとバケットのアップロード、ダウンロード、管理を行えます。 + +> **Bucket ACL の変更** (バケットを public/private にすること) はまだ CLI ではできません — ダッシュボードから管理してください。 + + + +## ストレージを拡張 + +```bash +lizard scale --service s3 --storage 16384 +``` + + + +## 関連項目 + +- [Managed Addons](/addons) — 命名、参照、ダッシュボードのブラウザーについて。 +- [サービス間参照](/variables/references) — 参照構文と解決方法。 diff --git a/_locales/ja/agents.mdx b/_locales/ja/agents.mdx new file mode 100644 index 0000000..8c66ebc --- /dev/null +++ b/_locales/ja/agents.mdx @@ -0,0 +1,92 @@ +--- +description: "AIコーディングエージェントから Lizard を操作: Lizard Skill を読み込み、--json でコマンドスキーマを確認し、Lizard CLI でデプロイします。" +--- + + + +# コーディングエージェント + +Lizard は、人間と同じくらい簡単に AI コーディングエージェントから操作できるよう設計されています。CLI には、エージェントにプラットフォーム全体を教える **組み込みスキル** が含まれており、すべてのコマンドは `--json` によって **自己記述的** なので、エージェントが推測に頼る必要はありません。 + + + +## 組み込みスキル + +正式な利用ガイドは CLI の内部にあり、CLI と一緒にバージョン管理されるため、常にインストール済みバージョンと一致します。エージェントは次でこれを読み取ります: + +```bash +lizard skills get core --json +``` + +これにより `{ name, frontmatter, content, … }` が返されます — `content` には完全なガイド（ビルドパイプライン、env の優先順位、アドオン、検出、終了コード）が含まれます。関連するサブコマンド: + +```bash +lizard skills list # available embedded skills +lizard skills get core # the core guide +lizard skills path # where skills are stored +``` + +ガイドはバイナリに同梱されているため、`lizard upgrade` を更新するとエージェントへの指示も更新されます。 + + + +## 自己記述的なコマンド + +エージェントは、暗記した構文に頼る代わりに、実行時に正確なフラグの形を確認します: + +```bash +lizard --help --json # full command tree + exit codes +lizard --help --json # a specific command's schema +``` + +[JSON と自動化](/cli/json) を参照してください。 + + + +## エージェントでのブートストラップ + +典型的なエージェントのフロー: + +1. **ガイドを読み込む:** `lizard skills get core --json` → `content` を読む。 +2. **認証を楽観的に確認する:** ユーザーのタスクを実行し、終了コード `2` の場合は `lizard login` を実行し、表示された URL をユーザーに渡してから再試行する。 +3. **変更前にコンテキストを解決する:** `lizard status` (cwd リンク) と `lizard ps --json` (サービス)。 +4. **ガイドに従って実行する** — `add`、`up`、`secrets`、`domain` など。常に `--json` を付けます。 + +`lizard` バイナリが存在しない場合は、最初にインストールしてください: + +```bash +npm install -g @lizard-build/cli +``` + + + +## エージェントが従うべき慣例 + +- 非対話呼び出しでは、**常に `--json` を付ける**。 +- **破壊的な操作を確認する**（サービスの削除、アドオンの削除、プロジェクト全体の secret の上書き、本番再起動）際はユーザーに確認する — CLI 自身のプロンプトは TTY 上でのみ動作します。 +- デフォルトでは **secret を利用するサービスのスコープに限定する**。`--global` は、公開値であることが明確に証明できる場合にのみ使います。[変数と Secrets](/variables#scoping) を参照してください。 +- **求められていないのに Dockerfile を書かない** — lizardpack はほとんどのスタックを自動検出します。まずはデプロイを試してください。[ビルドパイプライン](/concepts/build-pipeline) を参照してください。 +- **`lizard up` を使って git 連携サービスをアップロード方式へ切り替えない** — `service set` + `redeploy` を使います。 + + + +## エディタ統合 + +Lizard Skill は公開ブートストラップとして配布されているため、エディタやアシスタント内のエージェントは必要に応じてこれをインストールして読み込み、その後、このドキュメント全体で説明されているのと同じ CLI を操作できます。CLI が唯一の信頼できる情報源です — 学ぶべき別個のエージェント API はありません。 + +これは AI IDE にも当てはまります。アプリの作成やテストは行っても、ホスティングはしません。[Google Antigravity で構築したアプリをデプロイする](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command) を参照してください。デプロイ全体が 2 つのプロンプトで実行されます。 + + + +## 関連項目 + +- [`lizard skills`](/cli/skills) — 完全なコマンドリファレンス。 +- [JSON と自動化](/cli/json) — `--json` の出力とスキーマ確認。 +- [変数と Secrets](/variables#scoping) — エージェントが従うべき secret のスコープ慣例。 +- [Claude Code からアプリをデプロイする](https://lizard.build/blog/deploy-from-claude-code#deploy-from-claude-code-in-3-steps) — 同じブートストラップを、動かすためのプロンプト付きのウォークスルーとして記述したものです。 + + + +## 独自の MCP サーバーをホストする + +Lizard CLI を使うエージェントと、MCP を公開するアプリケーションは別のワークフローです。上記の CLI コマンドは MCP トランスポートを提供しません。Streamable HTTP を使って独自のサーバーをデプロイするには、[リモート MCP ガイド](/guides/deploy-mcp-server) に従ってください。 diff --git a/_locales/ja/cli/_meta.ts b/_locales/ja/cli/_meta.ts new file mode 100644 index 0000000..5ba0bb5 --- /dev/null +++ b/_locales/ja/cli/_meta.ts @@ -0,0 +1,46 @@ +export default { + index: "概要", + json: "JSONと自動化", + '-- auth': { type: "separator", title: "認証とアカウント" }, + login: "login", + logout: "logout", + whoami: "whoami", + workspace: "workspace", + '-- projects': { type: "separator", title: "プロジェクトとリンク" }, + init: "init", + link: "link", + unlink: "unlink", + status: "status", + project: "project", + config: "config", + '-- create': { type: "separator", title: "サービスとアドオンの作成" }, + add: "add", + '-- deploy': { type: "separator", title: "デプロイ" }, + up: "up", + redeploy: "redeploy", + restart: "restart", + '-- svc': { type: "separator", title: "サービス設定" }, + service: "service", + port: "port", + scale: "scale", + '-- secrets': { type: "separator", title: "シークレット" }, + secrets: "secrets", + '-- domains': { type: "separator", title: "ドメイン" }, + domain: "domain", + '-- observability': { type: "separator", title: "ログ、メトリクス、イベント" }, + logs: "logs", + metrics: "metrics", + events: "events", + ps: "ps", + '-- running': { type: "separator", title: "コマンドの実行" }, + run: "run", + ssh: "ssh", + '-- github': { type: "separator", title: "GitHub" }, + git: "git", + '-- misc': { type: "separator", title: "その他" }, + regions: "regions", + open: "open", + docs: "docs", + upgrade: "upgrade", + skills: "skills", +}; diff --git a/_locales/ja/cli/add.mdx b/_locales/ja/cli/add.mdx new file mode 100644 index 0000000..1d498e2 --- /dev/null +++ b/_locales/ja/cli/add.mdx @@ -0,0 +1,78 @@ +--- +description: "lizard add は、GitHub リポジトリ、空のサービス、またはマネージドアドオンからサービスを作成します。フラグの完全なリファレンスと実例付きです。" +--- + +# lizard add + +データベース、サービス、またはリポジトリをプロジェクトに追加します。 + + + +## 使い方 + +```bash +lizard add [types...] [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-r, --repo ` | GitHub リポジトリからサービスを作成 | +| `-s, --service ` | 空のサービスを作成 | +| `-a, --addon ` | マネージドアドオンを追加 (`postgres` / `redis` / `s3`) | +| `-n, --name ` | `${{name.KEY}}` 参照で使用する名前 | +| `-v, --variables ` | 環境変数を初期投入 (繰り返し指定可) | +| `--region ` | プロビジョニング先のリージョン | +| `--no-deploy` | リポジトリを接続するが最初のビルドはスキップ | +| `--list` | 利用可能なデータベースタイプを表示 | + + + +## 例 + + + +### GitHub リポジトリからサービスを作成 + +```bash +lizard add -r your-org/your-app +``` + +これにより `github` ソースのサービスが作成され、リポジトリをクローンし、スタックを自動検出してビルドし、稼働中の URL を返します。 + + + +### アドオンをプロビジョニング + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +### 空のサービスを作成 + +```bash +lizard add -s worker +``` + + + +### サービスに名前を付け、変数を初期投入 + +```bash +lizard add -r your-org/monorepo -n api +``` + + + +## 関連項目 + +- [GitHub からデプロイ](/deploy/github) — リポジトリの接続、プライベートアクセス、push 時の自動再デプロイ +- [Managed Addons](/addons) — postgres/redis/s3 のプロビジョニング、命名、利用 +- [lizard up](/cli/up) — リポジトリをリンクする代わりに、現在のディレクトリをアップロードしてデプロイ diff --git a/_locales/ja/cli/config.mdx b/_locales/ja/cli/config.mdx new file mode 100644 index 0000000..d4fd10a --- /dev/null +++ b/_locales/ja/cli/config.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard config apply は lizard-config.json ファイルをプロジェクトに反映し、変更を先に確認するための --dry-run フラグも利用できます。" +--- + +# lizard config + +`lizard-config.json` ファイルをプロジェクトに反映します。 + + + +## 使い方 + +```bash +lizard config apply [flags] +``` + + + +## サブコマンド + +### `lizard config apply` + +`lizard-config.json` ファイルをプロジェクトに反映します。 + +| フラグ | 説明 | +|------|-------------| +| `-f, --file ` | 設定ファイル（デフォルト: `lizard-config.json`） | +| `--dry-run` | 反映せずに何が変更されるかを表示 | + + + +## 例 + + + +### デフォルトの設定ファイルを反映する + +```bash +lizard config apply +``` + + + +### カスタムパスの設定ファイルを反映する + +```bash +lizard config apply -f ./configs/prod.json +``` + + + +### 反映せずに変更をプレビューする + +```bash +lizard config apply --dry-run +``` + + + +## 関連項目 + +- [lizard service](/cli/service) — 個別のサービスを管理 +- [Architecture](/concepts/architecture) — ワークスペース、プロジェクト、サービスの関係 diff --git a/_locales/ja/cli/docs.mdx b/_locales/ja/cli/docs.mdx new file mode 100644 index 0000000..87acc60 --- /dev/null +++ b/_locales/ja/cli/docs.mdx @@ -0,0 +1,33 @@ +--- +description: "lizard docs はターミナルから直接、デフォルトのブラウザで Lizard のドキュメントを開きます。使い方と例。" +--- + +# lizard docs + +ブラウザでドキュメントを開きます。 + + + +## 使い方 + +```bash +lizard docs +``` + + + +## 例 + + + +### ドキュメントサイトを開く + +```bash +lizard docs +``` + + + +## 関連項目 + +- [CLI リファレンス](/cli) — インストール、グローバルフラグ、終了コード diff --git a/_locales/ja/cli/domain.mdx b/_locales/ja/cli/domain.mdx new file mode 100644 index 0000000..50ccbcd --- /dev/null +++ b/_locales/ja/cli/domain.mdx @@ -0,0 +1,104 @@ +--- +description: "lizard domain はサービスのドメインを表示し、onlizard.com サブドメインを生成するか、自動 TLS 付きでカスタムホスト名を接続して検証します。" +--- + +# lizard domain + +現在のドメインを表示するか、カスタムドメインを接続します。 + + + +## 使い方 + +```bash +lizard domain [hostname] [flags] +``` + +ホスト名は位置引数です。`add` サブコマンドはありません。引数なしで `lizard domain` を実行すると、サービスの現在のドメインが表示されます。 + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-s, --service ` | サービス | +| `--port ` | 公開するポート | + + + +## サブコマンド + +### `lizard domain generate` + +新しい `*.onlizard.com` サブドメインを生成します。 + +### `lizard domain verify ` + +TXT レコードを確認してドメインを有効化します。TLS は自動的にプロビジョニングされます。 + +### `lizard domain delete ` + +ドメインを削除します（別名: `rm`）。 + +| フラグ | 説明 | +|------|-------------| +| `-y, --yes` | 確認をスキップ | + + + +## 例 + + + +### 現在のドメインを表示する + +```bash +lizard domain +``` + + + +### サブドメインを生成する + +```bash +lizard domain generate +``` + + + +### カスタムドメインを接続する + +```bash +lizard domain app.example.com --service web +``` + +Lizard は作成する DNS レコード（ホスト名用の `CNAME` と、検証用の `TXT` レコード）を返します。DNS プロバイダーでそれらを追加してから、検証します: + +```bash +lizard domain verify app.example.com +``` + + + +### 特定のポートにドメインを接続する + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +### ドメインを削除する + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes +``` + + + +## 関連項目 + +- [Networking](/networking) — 生成されるドメイン、TLS、worker サービス +- [リージョンにデプロイする](/deploy/regions) — サービスのリージョン選択 diff --git a/_locales/ja/cli/events.mdx b/_locales/ja/cli/events.mdx new file mode 100644 index 0000000..d4eed32 --- /dev/null +++ b/_locales/ja/cli/events.mdx @@ -0,0 +1,60 @@ +--- +description: "lizard events は、サービスのデプロイ履歴と現在のレプリカ状態を表示し、エントリ数を制限したり 1 つのサービスを対象にしたりするためのフラグを備えています。" +--- + +# lizard events + +デプロイ履歴とレプリカ状態を表示します。 + + + +## 使い方 + +```bash +lizard events [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-n, --limit ` | 表示するエントリ数 (デフォルト 10) | +| `-s, --service ` | 特定のサービスのイベントを表示 | + + + +## 例 + + + +### デプロイ履歴とレプリカ状態を表示 + +```bash +lizard events +``` + + + +### 特定のサービスのイベントを表示 + +```bash +lizard events --service api +``` + + + +### より多くのエントリを表示 + +```bash +lizard events --limit 25 +``` + + + +## 関連項目 + +- [Events & History](/observability/events) — 各エントリに含まれる内容と、ダッシュボードの デプロイメント ビューへの対応 +- [lizard ps](/cli/ps) — すべてのサービスの状態と URL をすばやく確認できるスナップショット +- [デプロイメント](/concepts/deployments) — デプロイのライフサイクル diff --git a/_locales/ja/cli/git.mdx b/_locales/ja/cli/git.mdx new file mode 100644 index 0000000..88f779b --- /dev/null +++ b/_locales/ja/cli/git.mdx @@ -0,0 +1,80 @@ +--- +description: "lizard git は GitHub App を接続し、リポジトリのステータスを報告し、再デプロイでサービスを別のブランチに切り替えます。" +--- + +# lizard git + +リンクされたプロジェクトとそのサービスの GitHub 接続を管理します。 + + + +## 使い方 + +```bash +lizard git connect +lizard git status +lizard git checkout [flags] +``` + + + +## サブコマンド + +### `lizard git connect` + +GitHub App を接続してプライベートリポジトリにアクセスします。 + +### `lizard git status` + +GitHub 接続とリポジトリのステータスを表示します。 + +### `lizard git checkout ` + +サービスを別のブランチに切り替えて再デプロイします。 + +| フラグ | 説明 | +|------|-------------| +| `--detach` | ログのストリーミングをスキップ | + + + +## 例 + + + +### GitHub App を接続する + +```bash +lizard git connect +``` + + + +### 接続とリポジトリのステータスを確認する + +```bash +lizard git status +``` + + + +### サービスを別のブランチに切り替える + +```bash +lizard git checkout api staging +``` + + + +### ログをストリーミングせずにブランチを切り替える + +```bash +lizard git checkout api staging --detach +``` + + + +## 関連項目 + +- [GitHub からデプロイ](/deploy/github) — リポジトリの接続、push 時の自動再デプロイ、モノレポの設定 +- [lizard add](/cli/add) — GitHub リポジトリからサービスを作成 diff --git a/_locales/ja/cli/index.mdx b/_locales/ja/cli/index.mdx new file mode 100644 index 0000000..d4a9991 --- /dev/null +++ b/_locales/ja/cli/index.mdx @@ -0,0 +1,88 @@ +--- +description: "lizard CLI をインストールおよびアップグレードし、認証し、すべてのコマンドのグローバルフラグ、終了コード、実行時スキーマ検出を確認します。" +--- + + + +# CLI リファレンス + +`lizard` CLI はプラットフォームへの主要なインターフェースです。このページでは、インストール、グローバルフラグ、終了コード、実行時検出について扱います。各コマンドにはサイドバーに専用のリファレンスページがあります — [`lizard up`](/cli/up)、[`lizard service`](/cli/service)、[`lizard secrets`](/cli/secrets) などを参照してください。 + +> CLI **v0.3.62** を基準に生成されたリファレンスです。任意のコマンドの正確でバージョン一致のスキーマを確認するには、`lizard --help --json` を実行してください。 + + + +## インストールとアップグレード + +```bash +npm install -g @lizard-build/cli +lizard --version +lizard upgrade # update to the latest version +lizard upgrade --check # check without installing +``` + +必ずグローバルにインストールされた `lizard` バイナリを使用してください — `npx` ではありません。権限エラーの修正については [Quickstart](/getting-started#1-install-the-cli) を参照してください。 + + + +## 認証 + +```bash +lizard login # browser OAuth +lizard login --token lzd_xxx # token auth +lizard logout +lizard whoami # current user, workspace, linked project +``` + +CI では、`login` を実行する代わりに、環境変数に `LIZARD_TOKEN` を設定してください。 + + + +## グローバルフラグ + +| フラグ | 説明 | +|------|-------------| +| `-V, --version` | CLI バージョンを表示 | +| `--json` | 機械可読な出力。`--help` と組み合わせると、コマンドのスキーマをダンプします | + +ほとんどのコマンドは、リンク済みのものではなく特定のリソースを対象にするために、`-p, --project`、`-s, --service`、`-w, --workspace` も受け付けます。 + + + +## 終了コード + +| コード | 意味 | 実行すべき手順 | +|------|---------|------------| +| `0` | 成功 | 続行 | +| `1` | 一般的なエラー | メッセージを確認 | +| `2` | 認証 (401/403) | `lizard login` を実行 | +| `3` | 見つからない (404) | `lizard ps` / `lizard project list` で名前を確認 | +| `4` | タイムアウト (408/504) | 再試行 | +| `5` | ユーザーによってキャンセル | 停止 | + + + +## 実行時検出 + +CLI は自己文書化されています。完全なコマンドツリー、グローバルフラグ、終了コードを確認するには、次を実行します。 + +```bash +lizard --help --json +``` + +任意のコマンドまたはサブコマンドの正確な引数とオプションを確認するには、次を実行します。 + +```bash +lizard --help --json +lizard --help --json # e.g. lizard service set --help --json +``` + +これは常にインストール済みのバージョンを反映します — フラグの形式を推測するよりこちらを優先してください。また、これはエージェントが CLI について事前学習されていなくても CLI を学習する方法でもあります: [Claude Code からのデプロイ](https://lizard.build/blog/deploy-from-claude-code) を参照してください。 + + + +## 設定と状態 + +- CLI は認証情報と現在のディレクトリのプロジェクトリンクを `~/.lizard/config.json` に保存します。 +- `lizard status` は cwd の workspace/project/service リンクを表示します（認証不要）。 +- `lizard config apply` は `lizard-config.json` ファイルをプロジェクトに適用します（プレビューには `--dry-run` を使用）。 diff --git a/_locales/ja/cli/init.mdx b/_locales/ja/cli/init.mdx new file mode 100644 index 0000000..35c6158 --- /dev/null +++ b/_locales/ja/cli/init.mdx @@ -0,0 +1,66 @@ +--- +description: "lizard init はプロジェクトを作成または選択し、現在のディレクトリにリンクします。CI で必要な明示的な形式も含みます。" +--- + +# lizard init + +プロジェクトを作成または選択し、現在のディレクトリにリンクします。 + + + +## 使い方 + +```bash +lizard init [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-n, --name ` | プロジェクト名（存在しない場合は作成） | +| `-w, --workspace ` | ワークスペースの id、slug、または名前 | +| `--force` | すでにリンクされていても再リンク | + + + +## 例 + + + +### 現在のディレクトリを対話的にリンクする + +```bash +lizard init +``` + + + +### CI で明示的にリンクする + +`lizard up` は TTY では `init` を実行しますが、非 TTY（CI）環境では、暗黙にプロジェクトを作成せずにエラーになります。まず明示的にリンクしてください: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +### すでにリンクされているディレクトリを再リンクする + +```bash +lizard init --name my-project --force +``` + + + +## 関連項目 + +- [lizard link](/cli/link) — 作成する代わりに、現在のディレクトリを既存のプロジェクトに関連付けます +- [lizard status](/cli/status) — 現在のディレクトリにリンクされたワークスペース、プロジェクト、およびサービスを表示します +- [lizard up](/cli/up) — 現在のディレクトリをアップロードしてデプロイします +- [Core 概念](/concepts/architecture) — プロジェクト、サービス、およびビルドパイプライン diff --git a/_locales/ja/cli/json.mdx b/_locales/ja/cli/json.mdx new file mode 100644 index 0000000..142fbc7 --- /dev/null +++ b/_locales/ja/cli/json.mdx @@ -0,0 +1,90 @@ +--- +description: "lizard CLI をスクリプト化: すべてのコマンドで --json、ストリーミングビルドでは行区切りイベント、スキーマ検出、CI でのトークン認証。" +--- + + + +# JSON と自動化 + +CLI はスクリプト化できるように作られています。機械可読な出力には `--json` を渡し、CI からはトークンで操作し、任意のコマンドのスキーマをランタイム時に検出できます。 + +この出力のもう 1 つの読み手は AI コーディングエージェントです — [Claude Code からのデプロイ](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) では、ビルド失敗時の JSON をどう扱うかを示しています。 + + + +## どこでも `--json` + +構造化出力のために、任意のコマンドに `--json` を追加します。stdout が TTY でない場合、CLI は自動的に JSON に切り替わります。 + +```bash +lizard ps --json +lizard secrets list --json +lizard metrics --json +``` + + + +### ストリーミングコマンド + +ストリーミングコマンドでは（`--detach` を付けない `lizard up`）、`--json` は **1 行につき 1 つの JSON オブジェクト** を出力します: + +```json +{ "event": "log", "line": "Step 1/8 : FROM node:20" } +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "running", "url": "https://app.onlizard.com" } +``` + +ストリームは `done`、または `error` / `failed` で終了します。`lizard up` はさらに、`status` と `url`（`null` の場合があります）を含む最終的な `deployed` / `failed` / `deploying` イベントを出力します。 + + + +### `logs --json` はストリームではなくスナップショットです + +`lizard logs --json` は **直近 200 行** を返し（`--tail N` で上書き可能、最大 1000）、終了します。さらに出力があることを期待して待機しないでください。特定のインシデントについては、`--restart latest` または `--restart ` を使用します。 + + + +## スキーマ検出 + +任意のコマンドの正確な引数、オプション、終了コードを出力します: + +```bash +lizard --help --json # whole tree + global flags + exit codes +lizard service set --help --json # one command +``` + +レスポンスの形式は `{ cli, version, command: { arguments, options, subcommands }, globalOptions, exitCodes }` です。これはインストール済みのバイナリから生成されるため、常に使用中のバージョンと一致します — フラグをハードコードするよりこちらを優先してください。 + + + +## CI / ヘッドレス利用 + +トークンで認証し、プロジェクトを明示的にリンクします（ヘッドレスな `up` ではプロジェクトは自動作成されません）: + +```bash +# Set LIZARD_TOKEN through your CI secret store. +lizard init --name my-project +lizard up --ci --service api --detach +``` + +終了コードを確認してパイプラインを分岐してください: + +| コード | 意味 | +|------|---------| +| `0` | 成功 | +| `1` | 一般的なエラー | +| `2` | 認証 — トークンがない / 期限切れ | +| `3` | 見つからない | +| `4` | タイムアウト | +| `5` | キャンセル済み | + +```bash +if lizard redeploy --service api --json; then + echo "Deploy succeeded" +else + status=$? + echo "Deploy failed with code $status" >&2 + lizard logs --build --json || true + exit "$status" +fi +``` diff --git a/_locales/ja/cli/link.mdx b/_locales/ja/cli/link.mdx new file mode 100644 index 0000000..4149652 --- /dev/null +++ b/_locales/ja/cli/link.mdx @@ -0,0 +1,62 @@ +--- +description: "lizard link は現在のディレクトリを既存のプロジェクトに関連付け、必要に応じて特定のサービスまたはワークスペースにも関連付けます。" +--- + +# lizard link + +現在のディレクトリを既存のプロジェクトに関連付けます（必要に応じてサービスも関連付けます）。 + + + +## 使い方 + +```bash +lizard link [service] [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-p, --project ` | プロジェクト名、slug、または ID | +| `-s, --service ` | 関連付けるサービス | +| `-w, --workspace ` | ワークスペース | + + + +## 例 + + + +### 既存のプロジェクトにリンクする + +```bash +lizard link --project my-project +``` + + + +### プロジェクトと特定のサービスにリンクする + +```bash +lizard link my-service --project my-project +``` + + + +### 特定のワークスペース内でリンクする + +```bash +lizard link --project my-project --workspace my-workspace +``` + + + +## 関連項目 + +- [lizard init](/cli/init) — プロジェクトを作成または選択し、1 つの手順でリンクします +- [lizard unlink](/cli/unlink) — 現在のディレクトリからリンクを削除します +- [lizard status](/cli/status) — リンクされているワークスペース、プロジェクト、サービスを表示します +- [Architecture: プロジェクト](/concepts/architecture) — ディレクトリとプロジェクトのリンクの仕組み diff --git a/_locales/ja/cli/login.mdx b/_locales/ja/cli/login.mdx new file mode 100644 index 0000000..5d58195 --- /dev/null +++ b/_locales/ja/cli/login.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard login はブラウザまたは API token を使って認証します。加えて、CI で LIZARD_TOKEN を使って非対話的に認証する方法も説明します。" +--- + +# lizard login + +Lizard にログインします。 + + + +## 使い方 + +```bash +lizard login [flags] +``` + +デフォルトでは、OAuth で認証するためにブラウザが開き、確認が完了するとターミナルに戻ります。 + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `--token ` | API token で認証 | + + + +## 例 + + + +### ブラウザでログイン + +```bash +lizard login +``` + + + +### token でログイン + +```bash +lizard login --token lzd_xxx +``` + + + +### CI で非対話的にログイン + +CI またはその他の非対話環境では、`login` を実行する代わりに、環境変数に `LIZARD_TOKEN` を設定します: + +```bash +export LIZARD_TOKEN=lzd_xxx +``` + + + +## 関連項目 + +- [lizard logout](/cli/logout) — ログアウト +- [lizard whoami](/cli/whoami) — 現在のユーザー、アクティブなワークスペース、リンクされたプロジェクトを表示 +- [CLI reference](/cli) — グローバルフラグ、終了コード、認証の概要 diff --git a/_locales/ja/cli/logout.mdx b/_locales/ja/cli/logout.mdx new file mode 100644 index 0000000..5b29d0a --- /dev/null +++ b/_locales/ja/cli/logout.mdx @@ -0,0 +1,22 @@ +--- +description: "lizard logout は Lizard CLI からサインアウトし、このマシンに保存されている認証情報を消去します。lizard login で再度ログインしてください。" +--- + +# lizard logout + +ログアウトします。 + + + +## 使い方 + +```bash +lizard logout +``` + + + +## 関連項目 + +- [lizard login](/cli/login) — Lizard で認証します +- [lizard whoami](/cli/whoami) — 現在のユーザー、アクティブなワークスペース、リンクされたプロジェクトを表示します diff --git a/_locales/ja/cli/logs.mdx b/_locales/ja/cli/logs.mdx new file mode 100644 index 0000000..5ef194c --- /dev/null +++ b/_locales/ja/cli/logs.mdx @@ -0,0 +1,93 @@ +--- +description: "lizard logs はサービスのランタイムログをストリーミングするか、--build、--tail、--level でビルドログ、再起動ログ、フィルタ済み履歴を取得します。" +--- + +# lizard logs + +サービスのランタイムログをストリーミングします。直近 200 行を表示したあと、ライブ tail を続けます。 + + + +## 使い方 + +```bash +lizard logs [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `--build` | 代わりにビルドログを表示 | +| `--tail ` | 直近 N 行（最大 1000） | +| `-l, --level ` | レベルでフィルタ | +| `--restarts [n]` | 最近の再起動を一覧表示 | +| `--restart ` | 特定の再起動前後のログ（最新は `latest`） | +| `-s, --service ` | サービス | + +`--json` を使うと、`lizard logs` はストリームではありません。直近 200 行を返し（`--tail N` で上書き、最大 1000）、終了します。スナップショットやスクリプトで使用してください。ライブストリームになるのは `--json` がない場合だけです。 + + + +## 例 + + + +### ランタイムログを tail する + +```bash +lizard logs +``` + + + +### 特定のサービスのログを tail する + +```bash +lizard logs --service api +``` + + + +### より多くの履歴を取得する + +```bash +lizard logs --tail 1000 +``` + + + +### ログレベルでフィルタする + +```bash +lizard logs --level error +``` + + + +### 最新のビルドを確認する + +```bash +lizard logs --build +``` + + + +### クラッシュまたは再起動を調査する + +```bash +lizard logs --restarts +lizard logs --restart latest +lizard logs --restart +``` + + + +## 関連項目 + +- [ログ](/observability/logs) — ランタイム、ビルド、再起動ログの挙動、および `lizard service logs` で履歴をページ送りする方法 +- [Incomplete Dockerfile](/deploy/troubleshooting/incomplete-dockerfile) — `lizard logs --build` から失敗したビルドを診断する +- [lizard events](/cli/events) — デプロイ履歴とレプリカのステータス +- [Claude Codeからデプロイする](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) — ビルド失敗時にエージェントが実行する、ログ確認、修正、再デプロイのループ diff --git a/_locales/ja/cli/metrics.mdx b/_locales/ja/cli/metrics.mdx new file mode 100644 index 0000000..c4148ef --- /dev/null +++ b/_locales/ja/cli/metrics.mdx @@ -0,0 +1,68 @@ +--- +description: "lizard metrics は、サービスの CPU、メモリ、ネットワーク、ディスクをレポートし、ライブの --watch 表示と任意のコスト数値を提供します。" +--- + +# lizard metrics + +CPU / メモリ / ネットワーク / ディスクとコストを表示します。 + + + +## 使い方 + +```bash +lizard metrics [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-r, --range ` | 時間範囲 | +| `-w, --watch` | ライブ更新 | +| `--cost` | コストを含める | + + + +## 例 + + + +### 現在のサービスのメトリクスを表示する + +```bash +lizard metrics +``` + + + +### 特定のサービスのメトリクスを表示する + +```bash +lizard metrics --service api +``` + + + +### メトリクスをライブで監視する + +```bash +lizard metrics --watch +``` + + + +### コストを含める + +```bash +lizard metrics --cost +``` + + + +## 関連項目 + +- [Metrics & cost](/observability/metrics) — ダッシュボード表示と使用状況に応じた対応 +- [Scaling](/deploy/scaling) — メトリクスに応じてサイズ変更またはレプリカを追加 diff --git a/_locales/ja/cli/open.mdx b/_locales/ja/cli/open.mdx new file mode 100644 index 0000000..85847e2 --- /dev/null +++ b/_locales/ja/cli/open.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard open は、現在のプロジェクトのダッシュボードをブラウザで起動します。これは CLI のビジュアルコンパニオンです。" +--- + +# lizard open + +ブラウザでプロジェクトを開きます。 + + + +## 使い方 + +```bash +lizard open +``` + + + +## 例 + + + +### 現在のプロジェクトのダッシュボードを開く + +```bash +lizard open +``` + + + +## 関連項目 + +- [ダッシュボード](/dashboard) — このコマンドで開く、CLI のビジュアルコンパニオン +- [Antigravity アプリを本番環境にデプロイする](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command) — 自分でコマンドを入力せずに、エージェントが実行するデプロイの反映を見届ける diff --git a/_locales/ja/cli/port.mdx b/_locales/ja/cli/port.mdx new file mode 100644 index 0000000..a39bdbe --- /dev/null +++ b/_locales/ja/cli/port.mdx @@ -0,0 +1,59 @@ +--- +description: "lizard port はサービスのコンテナポートを表示または変更します。0 に設定すると、そのサービスは受信ルーティングのない worker モードになります。" +--- + +# lizard port + +サービスのコンテナポートを表示または変更します。引数なしでは現在のポートを表示します（`worker mode` が `0` の場合）。 + + + +## 使い方 + +```bash +lizard port [value] [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-s, --service ` | 対象のサービス | + + + +## 例 + + + +### 現在のポートを表示する + +```bash +lizard port +``` + + + +### 特定のサービスのポートを設定する + +```bash +lizard port 0 -s worker +``` + + + +### worker サービスのポートを確認する + +```bash +lizard port --service worker +``` + + + +## 関連項目 + +- [Background workers](/deploy/workers) — ポートを `0` に設定すると、受信ルーティングなしでサービスを実行します +- [lizard service](/cli/service) — サービス設定の残りを管理します +- [Pythonアプリがホストに求めるもの](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) — `gunicorn` または `uvicorn` のプロセスが、`0.0.0.0` 上で `$PORT` にバインドする必要がある理由 diff --git a/_locales/ja/cli/project.mdx b/_locales/ja/cli/project.mdx new file mode 100644 index 0000000..3be476f --- /dev/null +++ b/_locales/ja/cli/project.mdx @@ -0,0 +1,56 @@ +--- +description: "lizard project は、ワークスペース内のプロジェクトを一覧表示するか、新しいプロジェクトを作成します。両方のサブコマンドの例も含まれています。" +--- + +# lizard project + +ワークスペース内のプロジェクトを一覧表示または作成します。 + + + +## 使い方 + +```bash +lizard project list +lizard project create +``` + + + +## サブコマンド + +### `lizard project list` + +ワークスペース内のすべてのプロジェクトを一覧表示します。 + +### `lizard project create` + +新しいプロジェクトを作成します。 + + + +## 例 + + + +### ワークスペース内のプロジェクトを一覧表示する + +```bash +lizard project list +``` + + + +### 新しいプロジェクトを作成する + +```bash +lizard project create +``` + + + +## 関連項目 + +- [lizard init](/cli/init) — プロジェクトを作成または選択し、現在のディレクトリにリンクします +- [lizard link](/cli/link) — 現在のディレクトリを既存のプロジェクトに関連付けます +- [Architecture](/concepts/architecture) — プロジェクトがワークスペースやサービスとどのように関係するか diff --git a/_locales/ja/cli/ps.mdx b/_locales/ja/cli/ps.mdx new file mode 100644 index 0000000..7b73d81 --- /dev/null +++ b/_locales/ja/cli/ps.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard ps は、リンクされたプロジェクト内のすべてのサービスを、そのステータスとライブ URL とともに一覧表示し、何が稼働しているかをすばやく確認できます。" +--- + +# lizard ps + +プロジェクト内のすべてのサービスを、ステータスと URL とともに一覧表示します。 + + + +## 使い方 + +```bash +lizard ps +``` + + + +## 例 + + + +### リンクされたプロジェクト内のサービスを一覧表示する + +```bash +lizard ps +``` + + + +## 関連項目 + +- [lizard status](/cli/status) — 現在のディレクトリに対して、リンクされたワークスペース、プロジェクト、サービスを表示します +- [lizard events](/cli/events) — デプロイ履歴とレプリカのステータスを表示します diff --git a/_locales/ja/cli/redeploy.mdx b/_locales/ja/cli/redeploy.mdx new file mode 100644 index 0000000..5852c07 --- /dev/null +++ b/_locales/ja/cli/redeploy.mdx @@ -0,0 +1,69 @@ +--- +description: "lizard redeploy は、現在の変数を使用して最新のコミットまたはアップロードから新しいビルドを開始し、--detach を渡さない限りログをストリーミングします。" +--- + +# lizard redeploy + +現在の変数を使用して新しいビルド（最新のコミット / 最後のアップロード）を開始します。 + + + +## 使い方 + +```bash +lizard redeploy [nameOrId] [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|--------------| +| `-s, --service ` | サービス | +| `--detach` | ビルドが受け付けられたら戻る | +| `--wait` | ビルドとデプロイの準備完了を待機します。`--json` と一緒に動作します | +| `--timeout ` | ビルド後の準備完了待機時間の上限。デフォルトは `120` | +| `--json` | スクリプト用に JSON を返します | + + + +## 例 + + + +### サービスを再ビルドして再デプロイする + +```bash +lizard redeploy --service api +``` + + + +### ログをストリーミングせずに再デプロイする + +```bash +lizard redeploy --service api --detach +``` + + + +### スクリプト内で待機する + +CLI 0.3.94 以降が必要です。HTTP を使わない worker では 0.3.95 以降を使用してください。 + +```bash +lizard --json redeploy --service api --wait --timeout 120 +``` + +`--wait` がない場合、JSON モードはビルドリクエストが受け付けられた時点で返ります。`--wait` がある場合、CLI はそのビルドを追跡し、その後デプロイの準備完了を待機します。JSON の結果には `buildId`、`ok`、`status` が含まれます。ビルドの失敗、準備完了チェックの失敗、またはタイムアウトでは、非ゼロの終了コードが返されます。 + +タイムアウトはビルド完了後の準備完了に適用されます。ビルド時間を制限したり、デプロイをキャンセルしたりはしません。`containerPort=0` を持つ worker は、HTTP チェックなしでバックエンドの準備完了ステータスを使用します。コマンドが正常に完了した後は、ワークフローでアプリケーションの動作確認が必要な場合、アプリケーションのエンドポイントまたは保存済みデータを確認してください。 + + + +## 関連項目 + +- [lizard restart](/cli/restart) — 現在のビルドをローリング再起動、再ビルドなし +- [lizard up](/cli/up) — 現在のディレクトリをアップロードしてデプロイします +- [デプロイメント](/concepts/deployments) — デプロイ、再起動、再ビルドの仕組み diff --git a/_locales/ja/cli/regions.mdx b/_locales/ja/cli/regions.mdx new file mode 100644 index 0000000..a79be2a --- /dev/null +++ b/_locales/ja/cli/regions.mdx @@ -0,0 +1,64 @@ +--- +description: "lizard regions は、アカウントで利用可能なリージョンを一覧表示し、サービスまたはアドオンの作成時に --region を渡す方法を示します。" +--- + +# lizard regions + +利用可能なリージョンを一覧表示します。 + + + +## 使い方 + +```bash +lizard regions [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `--json` | JSON として出力 | + + + +## 例 + + + +### 利用可能なリージョンを一覧表示する + +```bash +lizard regions +``` + + + +### リージョンを JSON として一覧表示する + +```bash +lizard regions --json +``` + + + +### サービスまたはアドオンの作成時にリージョンを選択する + +`--region ` を `lizard add` または `lizard up` に渡します: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +リージョンを指定しない場合、プラットフォームはプロジェクトのデフォルトを使用します。 + + + +## 関連項目 + +- [リージョン](/deploy/regions) — リージョンの選択、コロケーション、生成されるドメイン +- [`lizard add`](/cli/add) — `--region` でサービス、リポジトリ、またはアドオンを追加 diff --git a/_locales/ja/cli/restart.mdx b/_locales/ja/cli/restart.mdx new file mode 100644 index 0000000..4365301 --- /dev/null +++ b/_locales/ja/cli/restart.mdx @@ -0,0 +1,75 @@ +--- +description: "lizard restart は、再ビルドなしでサービスの現在のビルドをローリング再起動します。クラッシュからの復旧に役立ちます。" +--- + +# lizard restart + +現在のビルドをローリング再起動 — 再ビルドなし。 + + + +## 使い方 + +```bash +lizard restart [nameOrId] [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|--------------| +| `-s, --service ` | サービス | +| `--detach` | 再起動が受理されたら戻る | +| `--wait` | 新しい再起動試行が ready になるまで待機する。`--json` と併用可能 | +| `--timeout ` | `--wait` 使用時の readiness 待機時間の上限。デフォルトは `120` | +| `--json` | スクリプト用に JSON を返す | + + + +## 例 + + + +### サービスを再起動する + +```bash +lizard restart --service api +``` + + + +### ログをストリーミングせずに再起動する + +```bash +lizard restart --service api --detach +``` + + + +### 次のチェックを実行する前に待機する + +CLI 0.3.94 以降が必要です。HTTP を使わない worker では 0.3.95 以降を使用してください。 + +```bash +lizard --json restart --service api --wait --timeout 120 +``` + +`--wait` がない場合、JSON モードは再起動が受理された時点で返ります。`--wait` を付けると、結果には `ok`、`status`、`attemptId`、`waitedMs` が含まれます。CLI は新しい再起動試行を待機するため、リクエスト前から変わっていないステータスは成功として扱われません。待機の失敗またはタイムアウトでは、非ゼロの終了コードが返されます。 + +HTTP サービスでは、CLI はサービスドメインも 2 回確認します。`containerPort=0` を使う worker は、バックエンドの readiness ステータスを使用するため、生成されたドメインがある場合でも HTTP リスナーは不要です。 + +```bash +lizard --json restart --service worker --wait --timeout 60 +``` + +タイムアウトは、再起動リクエスト後の readiness 待機に適用されます。再起動自体はキャンセルされず、ネットワーク呼び出しによりコマンド全体の所要時間はさらに長くなる場合があります。ワークフローでプロセスの readiness 以上が必要な場合は、コマンド実行後にアプリケーションデータまたはヘルスエンドポイントを確認してください。 + + + +## 関連項目 + +- [lizard redeploy](/cli/redeploy) — 現在のものを再利用するのではなく、新しいビルドをトリガーする +- [lizard logs](/cli/logs) — `--restart latest` または `--restart ` を使って、再起動前後のログを確認する +- [デプロイメント](/concepts/deployments) — 再起動と再デプロイの違い、およびクラッシュからの復旧 diff --git a/_locales/ja/cli/run.mdx b/_locales/ja/cli/run.mdx new file mode 100644 index 0000000..7fb3bbb --- /dev/null +++ b/_locales/ja/cli/run.mdx @@ -0,0 +1,65 @@ +--- +description: "lizard run は、サービスのプロジェクトシークレットとサービスシークレットを注入した状態で、あなたのマシン上でコマンドを実行します。ssh を使うべき場合も含みます。" +--- + +# lizard run + +プロジェクトシークレットとサービスシークレットを注入した状態で、ローカルでコマンドを実行します。 + + + +## run と ssh の違い + +2 つのコマンドで、サービスのコンテキストを使ってコマンドを実行できます。実行される場所が異なるため、どちらが必要かを把握してください。 + +| コマンド | 実行場所 | 用途 | +|---------|-----------|---------| +| `lizard run` | ローカル。サービスの project + service secrets を注入した状態 | マイグレーション、シードスクリプト、本番設定が必要なローカルツール | +| `lizard ssh` | 実行中のサービスコンテナ内 | 稼働中コンテナの確認、単発のリモートコマンド、デバッグ | + +`lizard run` は、ローカルに注入された環境のコピーを表示します。通常は実行中のアプリが参照しているものと同じですが、稼働中コンテナに対して信頼できる情報源は `lizard ssh` です。実行中のアプリが実際に参照している内容を確認するには、代わりに `lizard ssh` を使ってください。 + + + +## 使い方 + +```bash +lizard run [flags] -- +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-s, --service ` | 環境変数を注入する対象のサービス | +| `--no-service` | サービス環境変数を注入しない | + + + +## 例 + + + +### サービスシークレットを注入してマイグレーションを実行する + +```bash +lizard run --service api -- node scripts/migrate.js +``` + + + +### 注入された環境変数を表示する + +```bash +lizard run --service api -- printenv DATABASE_URL +``` + + + +## 関連項目 + +- [lizard ssh](/cli/ssh) — ローカルではなく、実行中のサービスコンテナ内でコマンドを実行します +- [変数](/variables) — プロジェクト変数とサービス変数の定義方法および参照方法 +- [Pythonアプリホスティング](https://lizard.build/blog/python-app-hosting) — デプロイ済みデータベースに対して `manage.py` やその他のフレームワークツールを実行する方法 diff --git a/_locales/ja/cli/scale.mdx b/_locales/ja/cli/scale.mdx new file mode 100644 index 0000000..e457e32 --- /dev/null +++ b/_locales/ja/cli/scale.mdx @@ -0,0 +1,67 @@ +--- +description: "lizard scale はサービスのレプリカ数、CPU、メモリを変更し、アドオンのストレージを拡張します。各フラグで許可される値と例を示します。" +--- + +# lizard scale + +サービスをスケールします（レプリカ数 / CPU / メモリ / ストレージ）。 + + + +## 使い方 + +```bash +lizard scale [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `--replicas ` | レプリカ数 `1`–`10`（アプリ） | +| `--cpu ` | `1`、`2`、`3`、または `4` | +| `--memory ` | `128`–`8192` MB | +| `--storage ` | アドオンボリュームのサイズ、拡張のみ | + + + +## 例 + + + +### レプリカ数を水平方向にスケール + +```bash +lizard scale --service api --replicas 5 +``` + +各レプリカは、ロードバランサーの背後にある独立した pod です。レプリカを相互に置き換えられるように、アプリがステートレスであることを確認してください。 + + + +### CPU とメモリを垂直方向にスケール + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +### アドオンストレージを拡張 + +```bash +lizard scale --service postgres --storage 8192 +``` + +アドオンのデータボリュームは拡張のみです — ストレージは増やせますが、縮小はできません。 + + + +## 関連項目 + +- [Scaling](/deploy/scaling) — 水平スケーリングと垂直スケーリング、およびアドオンストレージの拡張 +- [lizard metrics](/cli/metrics) — スケール変更の前後で CPU / メモリ / ネットワーク / ディスクを確認 +- [lizard ps](/cli/ps) — スケール変更後にレプリカの状態を確認 +- [オブザーバビリティ → Metrics](/observability/metrics) — リソースとコストの監視 diff --git a/_locales/ja/cli/secrets.mdx b/_locales/ja/cli/secrets.mdx new file mode 100644 index 0000000..bd3922d --- /dev/null +++ b/_locales/ja/cli/secrets.mdx @@ -0,0 +1,100 @@ +--- +description: "lizard secrets は、サービスまたはプロジェクトのスコープで環境変数を設定、一覧表示、削除、インポートします。stdin からの dotenv インポートにも対応しています。" +--- + +# lizard secrets + +プロジェクトまたはサービスの secrets（環境変数）を管理します。 + + + +## 使い方 + +```bash +lizard secrets [args] [flags] +``` + + + +## サブコマンド + +### `lizard secrets set ...` + +1 つ以上の secret を設定します（可変長引数）。デフォルトのスコープはサービスです。`--global` はプロジェクトを対象にします。 + +| フラグ | 説明 | +|------|-------------| +| `--global` | プロジェクトスコープ | +| `-s, --service ` | サービススコープ | + +### `lizard secrets list` + +スコープ内の secret を一覧表示します。 + +| フラグ | 説明 | +|------|-------------| +| `--show` | 値を表示 | +| `--ref` | 参照を表示 | + +### `lizard secrets delete ...` + +1 つ以上の secret を削除します（可変長引数）。 + +### `lizard secrets import` + +stdin から dotenv ファイルをインポートします。 + + + +## 例 + + + +### リンクされたサービスに secrets を設定する + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + + + +### プロジェクト全体の secret を設定する + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +### secrets を一覧表示して値を表示する + +```bash +lizard secrets list +lizard secrets list --show +``` + + + +### secrets を削除する + +```bash +lizard secrets delete OLD_KEY ANOTHER_KEY +``` + + + +### dotenv ファイルをインポートする + +```bash +cat .env | lizard secrets import +``` + + + +## 関連項目 + +- [変数 & secrets](/variables) — スコープ、優先順位、ビルド時と実行時の動作 +- [サービス間参照](/variables/references) — あるサービスの値を別のサービスから読み取る +- [トラブルシューティング：シークレットや参照が反映されない](/variables/troubleshooting/reference-not-applied) +- [lizard run](/cli/run) — プロジェクト + サービスの secrets を注入してローカルでコマンドを実行 diff --git a/_locales/ja/cli/service.mdx b/_locales/ja/cli/service.mdx new file mode 100644 index 0000000..5abcde9 --- /dev/null +++ b/_locales/ja/cli/service.mdx @@ -0,0 +1,95 @@ +--- +description: "lizard service は、サービスの build、start、source、variable 設定を読み取り・編集し、rename、delete、logs、linking も処理します。" +--- + +# lizard service + +個々のサービスの設定、ソース、ライフサイクルを管理します。 + + + +## 使い方 + +```bash +lizard service set [flags] +lizard service show [flags] +lizard service rename +lizard service delete [flags] +lizard service logs +lizard service link +``` + + + +## サブコマンド + +### `lizard service set` + +サービスに build/start/source/variables/rename の変更を適用します。 + +| フラグ | 説明 | +|------|-------------| +| `--set =` | フィールドを設定します（繰り返し指定可） | +| `-f, --file ` | 適用する JSON 設定ファイル | +| `--force` | リモートで変更されていても上書きします | + +共通フィールドはフラットで、wire schema に 1:1 で対応します: `sourceType`, `repoUrl`, `branch`, `rootDirectory`, `dockerfilePath`, `buildCommand`, `startCommand`, `preDeployCommand`, `watchPatterns`, `containerPort`, `name`. + +`service set` は `configRevision` による楽観的並行制御を使用します。`409` が発生した場合は、`lizard service show` で設定を再読み込みし、調整して再試行するか、`--force` を渡してください。 + +### `lizard service show` + +現在のサービス設定を JSON として表示します。1 つのサービスだけに限定するには `-s` を使用します。 + +### `lizard service rename` + +サービスまたは addon の名前を変更します。その参照先（`${{name.KEY}}`）は安定したままです。 + +### `lizard service delete` + +サービスを削除します。`-y, --yes` は確認をスキップします。 + +### `lizard service logs` + +サービスのログをストリーミング表示します（[lizard logs](/cli/logs) も参照）。 + +### `lizard service link` + +サービスを現在のディレクトリにリンクします。 + + + +## 例 + + + +### サービスの build コマンドと start コマンドを更新する + +```bash +lizard service set api --set branch=main --set buildCommand="npm run build" +``` + + + +### サービスの完全な設定を確認する + +```bash +lizard service show -s api +``` + + + +### 確認プロンプトなしでサービスを削除する + +```bash +lizard service delete -y +``` + + + +## 関連項目 + +- [lizard port](/cli/port) — サービスのコンテナポートを表示または変更 +- [lizard scale](/cli/scale) — サービスのレプリカ数、CPU、メモリ、またはストレージをスケール +- [Architecture](/concepts/architecture) — サービスが project や addon とどう関連するか +- [ビルド pipeline](/concepts/build-pipeline) — `buildCommand`、`startCommand`、および source 設定がビルド時にどのように使用されるか diff --git a/_locales/ja/cli/skills.mdx b/_locales/ja/cli/skills.mdx new file mode 100644 index 0000000..d5cc32e --- /dev/null +++ b/_locales/ja/cli/skills.mdx @@ -0,0 +1,61 @@ +--- +description: "lizard skills は、このCLIバージョンに同梱されたエージェントガイドを読み取るため、AIエージェントは常にバイナリに一致する手順を取得できます。" +--- + +# lizard skills + +このCLIバージョンに同梱された埋め込みエージェントスキルを読み取ります。 + + + +## 使い方 + +```bash +lizard skills list +lizard skills get core +lizard skills path +``` + + + +## サブコマンド + +### `lizard skills list` + +利用可能な埋め込みスキルを一覧表示します。 + +### `lizard skills get core` + +コアガイドを読み取ります。これはプラットフォームの正式な使い方ガイドで、CLIとともにバージョン管理されています。`{ name, frontmatter, content, … }` を返します。ここで、`content` は完全なガイド（ビルドパイプライン、env の優先順位、アドオン、検出、終了コード）です。 + +### `lizard skills path` + +スキルがディスク上のどこに保存されているかを表示します。 + + + +## 例 + + + +### コアガイドをエージェントとして読み込む + +```bash +lizard skills get core --json +``` + + + +### 利用可能な埋め込みスキルを一覧表示する + +```bash +lizard skills list +``` + + + +## 関連項目 + +- [AI agents & MCP](/agents) — エージェントが埋め込みスキルと自己記述型コマンドでブートストラップする方法 +- [JSON & automation](/cli/json) — `lizard skills get core --json` で使用される `--json` 出力形式 +- [Claude Codeからデプロイする](https://lizard.build/blog/deploy-from-claude-code) — スキルのインストールと、デプロイをエージェントに渡すまでのエンドツーエンド diff --git a/_locales/ja/cli/ssh.mdx b/_locales/ja/cli/ssh.mdx new file mode 100644 index 0000000..06fda69 --- /dev/null +++ b/_locales/ja/cli/ssh.mdx @@ -0,0 +1,72 @@ +--- +description: "lizard ssh は稼働中のサービスコンテナ内でコマンドを実行し、その終了コードを返します。コンテナが実際に見ている内容を確認するための信頼できる方法です。" +--- + +# lizard ssh + +稼働中のサービスのコンテナ内でコマンドを実行し、その出力をストリーミングし、リモートの終了コードを返します。 + + + +## run と ssh + +`lizard run` と `lizard ssh` はどちらもサービスのコンテキストでコマンドを実行しますが、実行される場所が異なります。どちらが必要かを理解して選んでください。 + +| コマンド | 実行場所 | 用途 | +|---------|-----------|---------| +| `lizard run` | **ローカル**, サービスの project + service secrets が注入された状態 | マイグレーション、シードスクリプト、本番設定が必要なローカルツール | +| `lizard ssh` | **稼働中のサービスコンテナ内** | 稼働中コンテナの調査、単発のリモートコマンド、デバッグ | + +`lizard run` ではローカルに注入された環境のコピーが表示されます。これは通常本番環境と同じですが、稼働中コンテナが実際に見ている内容については `lizard ssh` が信頼できる基準です。 + + + +## 使用量 + +```bash +lizard ssh --service -- +``` + + + +## 例 + + + +### 稼働中アプリが見ている環境を確認する + +```bash +lizard ssh --service api -- env +``` + + + +### デプロイ済みイメージ内のファイルを一覧表示する + +```bash +lizard ssh --service api -- ls -la /app +``` + + + +### コンテナ内の OS を確認する + +```bash +lizard ssh --service api -- cat /etc/os-release +``` + + + +### シークレットが稼働中コンテナに反映されていることを確認する + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## 関連項目 + +- [lizard run](/cli/run) — 代わりにサービスの env を注入した状態でローカルでコマンドを実行する +- [変数](/variables) — シークレットや参照がサービスに渡る仕組み +- [Claude Codeからデプロイする](https://lizard.build/blog/deploy-from-claude-code#claude-code-deployment-compared-with-the-alternatives) — エージェントがなぜ稼働中コンテナへのシェルを必要とするのか、またそれを提供しないプラットフォームはどれか diff --git a/_locales/ja/cli/status.mdx b/_locales/ja/cli/status.mdx new file mode 100644 index 0000000..e37b81b --- /dev/null +++ b/_locales/ja/cli/status.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard status は、誤ったワークスペース、プロジェクト、サービスにデプロイする前に、現在のディレクトリがどれにリンクされているかを表示します。" +--- + +# lizard status + +現在のディレクトリについて、リンクされたワークスペース、プロジェクト、サービスを表示します。 + + + +## 使い方 + +```bash +lizard status +``` + + + +## 例 + + + +### 現在のディレクトリのリンクを確認する + +```bash +lizard status +``` + + + +## 関連項目 + +- [lizard init](/cli/init) — プロジェクトを作成または選択し、現在のディレクトリにリンクします +- [lizard link](/cli/link) — 現在のディレクトリを既存のプロジェクトに関連付けます +- [lizard whoami](/cli/whoami) — 現在のユーザー、アクティブなワークスペース、リンクされたプロジェクトを表示します diff --git a/_locales/ja/cli/unlink.mdx b/_locales/ja/cli/unlink.mdx new file mode 100644 index 0000000..1fb1f44 --- /dev/null +++ b/_locales/ja/cli/unlink.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard unlink は、現在のディレクトリと任意のプロジェクトのリンクを解除し、プロジェクト自体には変更を加えません。" +--- + +# lizard unlink + +現在のディレクトリと任意のプロジェクトの関連付けを解除します。 + + + +## 使い方 + +```bash +lizard unlink +``` + + + +## 例 + + + +### 現在のディレクトリのリンクを解除する + +```bash +lizard unlink +``` + + + +## 関連項目 + +- [lizard link](/cli/link) — 現在のディレクトリをプロジェクトに関連付ける +- [lizard status](/cli/status) — リンクされているワークスペース、プロジェクト、サービスを確認する diff --git a/_locales/ja/cli/up.mdx b/_locales/ja/cli/up.mdx new file mode 100644 index 0000000..846bf18 --- /dev/null +++ b/_locales/ja/cli/up.mdx @@ -0,0 +1,88 @@ +--- +description: "lizard up は現在のディレクトリをパッケージ化し、Lizard のビルドノード上でビルドして、稼働中の URL を返します。フラグ、CI での挙動、使用例。" +--- + +# lizard up + +現在のディレクトリをアップロードしてデプロイします。 + + + +## 使い方 + +```bash +lizard up [flags] +``` + +`up` は作業ツリーを tarball としてパッケージ化し、ビルドノードに送信してデプロイします。対象サービスで `sourceType=upload` を強制し、SSE 経由でビルドログをストリーミングし、完了時に稼働中の URL を表示します。 + +現在のディレクトリがまだプロジェクトにリンクされていない場合、`up` は最初に `init` を実行します。TTY では対話的に動作します。非 TTY（CI）環境では、無言でプロジェクトを作成することは**ありません**。代わりにエラーになり、`lizard init --name ` を実行するよう求めます（または `--name` を渡します）。これは、タイプミスによって空のプロジェクトが作成されるのを防ぐためです。 + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `-s, --service ` | 既存のサービスを対象にします | +| `--build-command ` | ビルドコマンドを上書きします | +| `--start-command ` | 起動コマンドを上書きします | +| `--pre-deploy-command ` | 各デプロイの前に 1 回実行します | +| `--port ` | コンテナポート（`0` = worker mode） | +| `--region ` | デプロイ先のリージョン | +| `-d, --detach` | デプロイを開始し、ログをストリーミングせずに終了します | +| `-c, --ci` | CI 向けの出力 | +| `--no-gitignore` | `.gitignore` を無視して、すべてをアップロードします | + + + +## サブコマンド + +### `lizard up status` + +進行中のアップロードデプロイの状態を報告します。 + + + +## 例 + + + +### 現在のディレクトリをデプロイする + +```bash +lizard up +``` + + + +### カスタム起動コマンドとポートを指定して特定のサービスにデプロイする + +指定した名前のサービスが存在しない場合は、先に `lizard add --service api` で作成してください。 + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +### CI でヘッドレスにデプロイする + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard add --service api +lizard up --ci --service api +``` + +サービスがすでに存在する場合は `lizard add` を省略してください。Lizard CLI 0.3.92 では、ビルドが失敗しても終了コード `0` で終了することがあります。CI リリースを成功と判断する前に、ビルドステータスとデプロイされた URL を確認してください。修正はリリース待ちです。macOS では、アーカイブに余分な `._*` メタデータファイルが入るのを避けるため、アップロード前に `COPYFILE_DISABLE=1` も設定してください。[framework setup](/framework-guides#prepare-the-project) を参照してください。 + + + +## 関連項目 + +- [ローカルコードからデプロイ](/deploy/upload) — アップロードベースのデプロイの完全な手順 +- [lizard redeploy](/cli/redeploy) — 再アップロードせずに最後のアップロードを再ビルドします +- [lizard init](/cli/init) — デプロイ前に明示的にプロジェクトを作成またはリンクします +- [Worker services](/deploy/workers) — `--port 0` の意味 +- [設定せずにコンテナをデプロイする](https://lizard.build/blog/container-as-a-service#deploy-a-container-without-configuring-one) — container-as-a-service プラットフォームの中でこのコマンドがどこに位置するか diff --git a/_locales/ja/cli/upgrade.mdx b/_locales/ja/cli/upgrade.mdx new file mode 100644 index 0000000..3593629 --- /dev/null +++ b/_locales/ja/cli/upgrade.mdx @@ -0,0 +1,50 @@ +--- +description: "lizard upgrade は CLI をその場で更新します。--check を付けると、インストールせずに新しいバージョンがあるか確認します。" +--- + +# lizard upgrade + +CLI を最新バージョンに更新します。 + + + +## 使い方 + +```bash +lizard upgrade [flags] +``` + + + +## フラグ + +| フラグ | 説明 | +|------|-------------| +| `--check` | インストールせずに新しいバージョンがあるか確認 | + + + +## 例 + + + +### 最新バージョンに更新 + +```bash +lizard upgrade +``` + + + +### インストールせずに更新を確認 + +```bash +lizard upgrade --check +``` + + + +## 関連項目 + +- [CLI リファレンス](/cli) — インストール、グローバルフラグ、終了コード +- [はじめに](/getting-started) — 初めて CLI をインストールする diff --git a/_locales/ja/cli/whoami.mdx b/_locales/ja/cli/whoami.mdx new file mode 100644 index 0000000..6f3a712 --- /dev/null +++ b/_locales/ja/cli/whoami.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard whoami は、ログイン中のアカウント、アクティブなワークスペース、このディレクトリにリンクされているプロジェクトを表示します。" +--- + +# lizard whoami + +現在のユーザー、アクティブなワークスペース、リンクされているプロジェクトを表示します。 + + + +## 使い方 + +```bash +lizard whoami +``` + + + +## 例 + + + +### 現在どのアカウントでログインしているかを確認する + +```bash +lizard whoami +``` + + + +## 関連項目 + +- [lizard login](/cli/login) — 身元を確認する前に認証します +- [lizard status](/cli/status) — 現在のディレクトリにリンクされているワークスペース、プロジェクト、サービスを表示します +- [lizard workspace](/cli/workspace) — アクセスできるワークスペースを一覧表示します diff --git a/_locales/ja/cli/workspace.mdx b/_locales/ja/cli/workspace.mdx new file mode 100644 index 0000000..935d0ed --- /dev/null +++ b/_locales/ja/cli/workspace.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard workspace list は、あなたのアカウントがアクセスできるすべてのワークスペースと、ワークスペースがプロジェクトやサービスとどう関係するかを表示します。" +--- + +# lizard workspace + +アクセスできるワークスペースを一覧表示します。 + + + +## 使い方 + +```bash +lizard workspace list +``` + + + +## 例 + + + +### ワークスペースを一覧表示する + +```bash +lizard workspace list +``` + + + +## 関連項目 + +- [lizard whoami](/cli/whoami) — アクティブなワークスペースを表示します +- [Architecture: ワークスペース](/concepts/architecture) — ワークスペースがプロジェクトやサービスとどう関係するか diff --git a/_locales/ja/concepts/_meta.ts b/_locales/ja/concepts/_meta.ts new file mode 100644 index 0000000..48c3de9 --- /dev/null +++ b/_locales/ja/concepts/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "概要", + architecture: "アーキテクチャ", + 'build-pipeline': "ビルドパイプライン", + deployments: "デプロイメント", +}; diff --git a/_locales/ja/concepts/architecture.mdx b/_locales/ja/concepts/architecture.mdx new file mode 100644 index 0000000..609a695 --- /dev/null +++ b/_locales/ja/concepts/architecture.mdx @@ -0,0 +1,126 @@ +--- +description: "Lizard が作業を workspace、project、service にどのように整理するかに加えて、managed addons、cross-resource references、injected variables について説明します。" +--- + + + +# アーキテクチャ + +Lizard は、デプロイするすべてのものを 3 層の階層に整理し、さらに project に紐づく managed addons を提供します。 + +``` +workspace +└── project + ├── service (app) ← built from GitHub or an upload + ├── service (worker) ← background job, no HTTP port + └── addons + ├── postgres + ├── redis + └── s3 +``` + + + +## ワークスペース + +**workspace** はアカウントまたは organization のレベルです。少なくとも 1 つの workspace に所属し、課金、メンバー、project はその配下にあります。アクセスできるものを一覧表示するには、次を実行します: + +```bash +lizard workspace list +lizard whoami # shows your active workspace +``` + +同じ project 名が複数の workspace に存在する場合に区別できるよう、多くのコマンドは `-w, --workspace ` を受け付けます。 + + + +## プロジェクト + +**project** は、workspace 内で関連する service と addons をまとめる単位です。作業ディレクトリは project に *link* され、その link（`~/.lizard/config.json` に保存されます）によって CLI は対象を判別します。 + +```bash +lizard init --name my-project # create or select a project, link the cwd +lizard link --project my-project # link to an existing project +lizard status # show the current directory's link +lizard unlink # remove the link +lizard project list # all projects in the workspace +``` + +> **ヒント:** project には repo 名またはディレクトリ名を使い、service にはアプリらしい名前（`api`、`worker`、`web`）を使ってください。 + + + +## サービス + +**service** は単一のデプロイ可能な unit です。その source は次のいずれかです: + +- **`github`** — 接続された GitHub repo。追跡対象ブランチへの push により自動で再デプロイされます。 +- **`upload`** — `lizard up` でアップロードされた tarball。 + +実行中の各 service は、それぞれ独立した **isolated pod** として動作し、default-deny の network policy、生成された `..onlizard.com` domain、自動 TLS を備えます。この分担、つまりコンテナはあなたが用意し、platform がそれを実行するという形は [container as a service](https://lizard.build/blog/container-as-a-service) であり、blog ではそれでもなお利用者側に残る責任について説明しています。service の確認と管理には次を使います: + +```bash +lizard ps # list services with status + URL +lizard service show # full config as JSON +lizard service set --set = +lizard service rename --service +lizard service delete --service +``` + +サービス configuration fields は **flat** で、wire schema に 1:1 で対応しています（例: `repoUrl`、`branch`、`buildCommand`、`startCommand`、`containerPort`、`rootDirectory`）。`build.*` / `deploy.*` のようなネストはありません。完全な一覧は [`lizard service`](/cli/service) を参照してください。 + + + +### App と worker service + +デフォルトでは、service はポート（デフォルトは `3000`）で待ち受けし、その domain で提供される **HTTP app** です。ポートで待ち受けしない service、たとえば queue consumer、reconciler、polling loop は、`containerPort=0` を設定して [**worker mode**](/deploy/workers) で実行する必要があります。worker はポートの注入、到達性の health check、load-balancer への登録をスキップします。 + + + +## マネージドアドオン + +**addons** は、project ごとにプロビジョニングする managed Postgres、Redis、および S3 互換 storage です: + +```bash +lizard add postgres redis s3 +``` + +各 addon は固定された一連の環境変数を公開し、service はそれらを **reference**（`${{.KEY}}`）によって利用します。[Managed Addons](/addons) を参照してください。 + + + +## リソース間参照 + +任意の service または addon の値は、別の resource の環境変数から次の形式で参照できます: + +``` +${{.}} +``` + +reference はデプロイ時に、対象のマージ済み環境に対して解決されます。ID で保存されるため、後で対象の名前を変更しても reference は壊れません。存在しない対象または key への reference は空文字列に解決されます（デプロイは**失敗しません**）。失敗するのは circular references の場合だけです。 + +```bash +# Wire a service to the project's Postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + +実際に consumer がその値を受け取ったことを確認するには、次を実行します: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## プラットフォーム注入変数 + +すべての service は自動的に次の変数を受け取ります（これらは上書きできません）: + +| 変数 | 説明 | +|----------|-------------| +| `PORT` | アプリが待ち受けるべきポート（worker mode では省略） | +| `LIZARD_SERVICE_NAME` | service の名前 | +| `LIZARD_PROJECT_ID` | project ID | +| `LIZARD_PUBLIC_DOMAIN` | service の public domain | + +これらが独自の変数とどのように相互作用するか、および完全な優先順位については [変数 & Secrets](/variables) を参照してください。 diff --git a/_locales/ja/concepts/build-pipeline.mdx b/_locales/ja/concepts/build-pipeline.mdx new file mode 100644 index 0000000..25a5534 --- /dev/null +++ b/_locales/ja/concepts/build-pipeline.mdx @@ -0,0 +1,89 @@ +--- +description: "Lizard がソースをコンテナイメージに変換する方法: 合成された Dockerfile、リポジトリの Dockerfile、または lizardpack の自動検出、そして何が再ビルドを引き起こすか。" +--- + + + +# ビルドパイプライン + +ビルドは Lizard のビルドノード上で実行されます — **ローカルに Docker は不要です**。デプロイすると、プラットフォームは固定の判定順序に従って、ソースをどのようにコンテナイメージへ変換するかを決定し、その後そのイメージを分離された pod で実行します。すべての [container as a service](https://lizard.build/blog/container-as-a-service) がイメージをビルドしてくれるわけではありません。このブログでは、このカテゴリにある 3 つの形態を比較しています。 + + + +## ビルドの判定順序 + +プラットフォームは次の順序で、ビルド戦略をちょうど 1 つ選びます: + +1. **合成された Dockerfile** — サービスに `buildCommand` および/または `startCommand` が設定されている場合（または `lizard up --build-command` / `--start-command` 経由で渡された場合）、Lizard はそれらのコマンドから Dockerfile を生成します。lizardpack は呼び出されません。 +2. **リポジトリの Dockerfile（そのまま）** — サービスに `dockerfilePath` が設定されている場合、リポジトリ内のその Dockerfile が変更されずに使用されます。 +3. **lizardpack 自動検出** — それ以外の場合、プラットフォームはソースをクローンし、ビルドパック / Dockerfile ジェネレーターである **lizardpack** を実行します。 + + + +### lizardpack 自動検出 + +lizardpack はリポジトリを検査し、最適化されたマルチステージイメージをビルドします。サポートされるスタックは次の順序で照合されます: + +**Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static** + +本番用スクリプト、アダプター、出力パス、ポートについては [フレームワーク guides](/framework-guides) を参照してください。検出はプロジェクトファイルと依存関係を使用します。複数のプロバイダーに一致するリポジトリは、この順序に従います。 + +この経路では: + +- リポジトリに `Dockerfile` が存在し、**かつ** 実際のビルドステップ（`RUN ` の行であり、単なる `COPY dist/` ではない）がある場合、それがそのまま使用されます。 +- それ以外の場合、lizardpack が Dockerfile を生成します。 +- **開始コマンド** は自動検出されます: `Procfile` `web:` の行（Python/Ruby）または `package.json` `scripts.start`（Node）が自動的に検出されます。Django、Flask、FastAPI がそれぞれ必要とする正確な行については、[Pythonアプリホスティング](https://lizard.build/blog/python-app-hosting) を参照してください。 +- **ポート** は `EXPOSE`、フレームワークのデフォルト、または明示的な `PORT` 環境変数から推定されます。 + +> **注意:** 事前ビルド済みアーティファクトのみをコピーする Dockerfile（`COPY dist/`、`build/`、`out/`、`.next/`、`public/`）で、`RUN` のビルドステップが**ない**場合は、不完全と見なされ、lizardpack によって再生成されます。実際のビルドステップを追加するか、`dockerfilePath` を設定してそのまま使用するよう強制してください。 + + + +## 何が再ビルドを引き起こすか + +| アクション | Rebuilds? | +|--------|-----------| +| 追跡対象ブランチへの `git push` | ✅ GitHub webhook 経由 | +| `lizard redeploy` / `lizard up` | ✅ 明示的 | +| `VITE_*` または `NEXT_PUBLIC_*` 変数の変更 | ✅ ビルド時の値は焼き込まれます | +| ビルドフィールド（`repoUrl`、`branch`、`sourceType`、`buildCommand`、`dockerfilePath`、`rootDirectory`）の `service set` | ✅ 自動的に再ビルド | +| ランタイム専用フィールド（`startCommand`、`preDeployCommand`、`containerPort`、`watchPatterns`）の `service set` | ❌ 適用するには `lizard redeploy` を実行 | +| その他の環境変数 / シークレットの変更 | ❌ クイック再起動で適用（再ビルドなし） | + +> **二重にビルドしないでください。** ビルドフィールドを変更する `service set` の後は、再ビルドが自動的に発火します — その後に `lizard redeploy` を続けないでください。2 回目の冗長なビルドがキューに入ります。 + + + +## ビルドを監視する + +ビルドログは `lizard up` 中にストリーミングされます。どのサービスでも: + +```bash +lizard logs --build # the most recent build's logs +lizard events # deploy history + replica status +``` + +ビルドが失敗した場合は、`lizard logs --build` を読み、原因を修正し（リポジトリ内、または `lizard service set` 経由で `buildCommand` / `startCommand` を調整して）、その後 `lizard redeploy` を実行してください。 + + + +## ランタイムに関する注意 + +- **Docker の `HEALTHCHECK` はありません。** ランタイムは Docker の healthcheck ループを実行しないため、`HEALTHCHECK` ディレクティブは無視されます。代わりに Lizard はポートに対して TCP プローブを実行します（[worker mode](/deploy/workers) ではスキップされます）。 +- **求められていないのに Dockerfile を書かないでください。** lizardpack はほとんどのスタックを自動検出します — まずデプロイを試し、自動ビルドが合わない場合にのみ Dockerfile を追加する（または `dockerfilePath` を設定する）ようにしてください。 + + + +## ビルド設定リファレンス + +| フィールド | 説明 | +|-------|-------------| +| `buildCommand` | アプリをビルドするコマンド → **合成された Dockerfile** 経路を強制 | +| `startCommand` | ランタイムでアプリを起動するコマンド | +| `preDeployCommand` | 各デプロイ前に 1 回実行されます（例: DB マイグレーション） | +| `dockerfilePath` | **そのまま**使用する、リポジトリ内 Dockerfile へのパス | +| `rootDirectory` | ビルド元のサブディレクトリ（モノレポ） | +| `watchPatterns` | 一致するパスが変更された場合のみ再デプロイ | +| `containerPort` | アプリが listen する TCP ポート（デフォルト `3000`; `0` = [worker](/deploy/workers)） | + +これらはいずれも `lizard service set --set =` で設定できます。[`lizard service`](/cli/service) を参照してください. diff --git a/_locales/ja/concepts/deployments.mdx b/_locales/ja/concepts/deployments.mdx new file mode 100644 index 0000000..23be746 --- /dev/null +++ b/_locales/ja/concepts/deployments.mdx @@ -0,0 +1,95 @@ +--- +description: "Lizard におけるデプロイのライフサイクル: 何がビルドをトリガーするのか、トラフィックが正常なレプリカへどのように切り替わるのか、そして再起動と再デプロイの違い。" +--- + + + +# デプロイの仕組み + +**deployment** とは、サービスの 1 回のビルドとリリースのことです。リリース経路はサービスのランタイムによって異なります。ビルドが成功しただけでは、アプリケーションが起動したことやリクエストを処理できることは証明されません。 + + + +## デプロイが行われる仕組み + +デプロイは、次のいずれかによってトリガーされます: + +- 追跡対象ブランチへの **`git push`**（`github`-source サービスの場合）。 +- **`lizard redeploy`** — 最新のコミット（git）または最後のアップロードから、現在の変数を使って再ビルドします。 +- **`lizard up`** — 現在のディレクトリをアップロードしてデプロイします。 +- ビルドに影響するフィールドを変更する **`service set`**。 + +```bash +lizard redeploy --service api # rebuild + redeploy from current source +lizard up # upload cwd and deploy +``` + + + +## ライフサイクル + +1. **ビルド** — プラットフォームがビルドを実行します（[ビルド Pipeline](/concepts/build-pipeline) を参照）。 +2. **Pre-deploy** — `preDeployCommand` が設定されている場合、1 回だけ実行されます（例: マイグレーション）。 +3. **Start** — Lizard が設定されたランタイムでアプリケーションを起動します。 +4. **Health check** — プラットフォームがアプリのポートに到達可能かを確認します（[workers](/deploy/workers) ではスキップされます）。 +5. **Verify** — リリースのステータスを確認し、アプリケーション URL を呼び出します。ポート到達性は完全なアプリケーションヘルスチェックではありません。 + + + +## ストリーミング出力 + +非デタッチの `lizard up`（または `redeploy`）を実行すると、ビルドログがライブでストリーミングされます。`--json` を使うと、1 行ごとに 1 つの JSON イベントを受け取れます: + +```json +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "...", "url": "https://..." } +``` + +最後は `deployed`、`failed`、または `deploying` で終了します。`--detach` を使うと、ストリーミングせずにデプロイを開始してすぐに戻れます。 + + + +## 履歴の確認 + +```bash +lizard events # deploy history + per-replica status +lizard events --limit 25 # show more +lizard ps # current services, status, and URLs +``` + +[ダッシュボード](/dashboard) では、**デプロイメント** ビューに完全なタイムライン、デプロイごとのビルドログ、各リリースの詳細ドロワーが表示されます。 + + + +## 再起動と再デプロイ + +| コマンド | 何をするか | +|---------|--------------| +| `lizard restart --service ` | **現在の** ビルドを再起動 — 再ビルドなし | +| `lizard redeploy --service ` | 最新のコミット/アップロードから新しく **ビルド** し、その後リリース | + +`restart` はレプリカを再循環させるために使います（例: ホットリロードされなかったランタイムシークレットを反映するため）。新しいビルドが必要な場合は `redeploy` を使ってください。 + + + +## クラッシュからの復旧 + +直近のクラッシュまたは再起動のログを確認します: + +```bash +lizard logs --restart latest # log tail around the latest restart +lizard logs --restart # a specific restart +lizard events # see replica status +``` + + + +## 設定変更（再ビルドなし） + +ほとんどの環境変数とシークレットの変更は、再ビルドなしで適用されます。Lizard はサービスの設定を更新して再起動し、これには数秒かかります。ビルド時の値（`VITE_*`、`NEXT_PUBLIC_*`）とビルドフィールドの変更は再ビルドを強制します — [再ビルドトリガー表](/concepts/build-pipeline#what-triggers-a-rebuild) を参照してください。 + + + +## 失敗したリリースと復旧 + +ビルドの失敗とアプリケーション起動の失敗は別のケースです。どのランタイムでも古いリリースが引き続き配信されるとは想定しないでください。アクティブなサービス、ビルドログ、ランタイムログを確認してください。`lizard redeploy` は選択したソースを再度ビルドします。以前のビルドを復元するためのコマンドではありません。必要に応じてソースコミットを元に戻し、それをデプロイして結果を確認してください。[既知の問題](/platform/known-issues) を参照してください。 diff --git a/_locales/ja/concepts/index.mdx b/_locales/ja/concepts/index.mdx new file mode 100644 index 0000000..6fe35e3 --- /dev/null +++ b/_locales/ja/concepts/index.mdx @@ -0,0 +1,19 @@ +--- +description: "Lizard の中核モデル: コードがどのように整理され、どのようにビルドされ、リリースがどのように本番環境へ届くか。" +--- + + + +# 概念 + +Lizard の中核モデル: コードがどのように整理され、どのようにビルドされ、リリースがどのように本番環境へ届くか。これを一度読めば、残りのドキュメントが理解しやすくなります。 + +1 つ上のレベルのモデル、つまりコンテナを代わりに実行してくれるプラットフォームが何と呼ばれるか、そしてそれが PaaS、FaaS、IaaS とどう違うかについては、ブログの [container as a service](https://lizard.build/blog/container-as-a-service) を読んでください。 + + + +## このセクションの内容 + +- [アーキテクチャ](/concepts/architecture) — workspace → project → service の階層、マネージドアドオン、クロスリソース参照。 +- [ビルドパイプライン](/concepts/build-pipeline) — ソースがどのようにコンテナイメージになるか（合成された Dockerfile、リポジトリの Dockerfile、または lizardpack の自動検出）と、何が再ビルドのトリガーになるか。 +- [デプロイメント](/concepts/deployments) — ビルドとリリースのライフサイクル、再起動と再デプロイの違い、およびライブ設定変更。 diff --git a/_locales/ja/dashboard.mdx b/_locales/ja/dashboard.mdx new file mode 100644 index 0000000..7dc5971 --- /dev/null +++ b/_locales/ja/dashboard.mdx @@ -0,0 +1,96 @@ +--- +description: "LizardダッシュボードがCLIに追加するもの: サービスのステータス、デプロイのタイムライン、ストリーミングログ、メトリクス、データブラウザー、チーム、請求。" +--- + + + +# アプリダッシュボード + +LizardダッシュボードはCLIのビジュアルな補完機能です。`lizard …` で行うことはすべてここにも反映され、さらに UI のほうが簡単なもの — ストリーミングログ、チャート、データブラウザー、チーム/請求管理 — も利用できます。 + +端末をまったく開きたくない場合は、エージェントにコマンドを実行させて、ここで結果を確認してください — [Antigravity アプリを本番環境にデプロイする](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command) の手順では、2 つのプロンプトだけで、端末に何も入力する必要はありません。 + +CLI から開く: + +```bash +lizard open # open the current project +lizard docs # open this documentation +``` + + + +## ダッシュボードにあるもの + + + +### サービス + +プロジェクトのホームビューには、すべてのサービスがステータスバッジ、生成されたドメイン、ログ・メトリクス・シークレット・設定へのクイックアクセスとともに一覧表示されます。新しいサービス（GitHub リポジトリから、または空の状態から）もここから直接作成できます。 + + + +### デプロイ + +すべてのデプロイのタイムラインが表示され、デプロイごとのビルドログと詳細ドロワー（コミット、ステータス、レプリカ）を確認できます。これは `lizard events` + `lizard logs --build` に相当するビジュアル版です。 + + + +### ログ + +検索とレベルフィルターに対応した、ランタイムログとビルドログのライブストリーミング — [`lizard logs`](/observability/logs) に対応する UI です。 + + + +### メトリクスと使用状況 + +サービスごとの CPU、メモリ、ネットワーク、ディスクのチャートに加え、プロジェクト全体の消費量とコストを内訳表示する **使用量** ビューがあります。[`lizard metrics --cost`](/observability/metrics) に対応します。 + + + +### 変数 & Secrets + +マスクされた値と参照（`${{…}}`）サポート付きで、サービススコープおよびプロジェクトスコープのシークレットを管理できます。[変数 & Secrets](/variables) を参照してください。 + + + +### ドメイン + +カスタムドメインの追加、DNS レコードの表示、検証と TLS ステータスの追跡ができます。[Networking](/networking) を参照してください。 + + + +### Managed addon ブラウザー + +各 addon にはデータブラウザーが付属しています: + +- **Postgres** — データのクエリと編集ができる SQL/テーブルエディター。 +- **Redis** — キー/バリューブラウザー。 +- **S3** — アップロード/ダウンロードに対応したバケット/オブジェクトブラウザー。 + + + +### GitHub 連携 + +GitHub App を接続し、リポジトリを選択して、Lizard がビルドできるリポジトリを管理します。[GitHubからデプロイする](/deploy/github) を参照してください。 + + + +### 設定、チーム、請求 + +プロジェクトとワークスペースの設定、メンバー招待とロール、リソース使用量、アカウントクレジット、任意の自動チャージに対応しています。標準アカウントは月額サブスクリプションなしの [pay as you go](/platform/billing) を利用します。 + + + +## CLI ↔ ダッシュボード + +| タスク | CLI | ダッシュボードビュー | +|------|-----|----------------| +| デプロイ履歴 | `lizard events` | デプロイメント | +| ログをストリーミング | `lizard logs` | ログ | +| リソースチャート | `lizard metrics` | Metrics / 使用量 | +| シークレットを管理 | `lizard secrets` | 変数 | +| カスタムドメイン | `lizard domain` | ドメイン | +| Postgres/Redis/S3 を閲覧 | `lizard run` / `lizard ssh` | アドオンブラウザー | +| チームメンバーを招待 | — | Team / Settings | + +そのときに合うほうを使ってください — どちらも同じプロジェクトとサービスを操作します。 diff --git a/_locales/ja/deploy/_meta.ts b/_locales/ja/deploy/_meta.ts new file mode 100644 index 0000000..8fa9111 --- /dev/null +++ b/_locales/ja/deploy/_meta.ts @@ -0,0 +1,9 @@ +export default { + index: "概要", + github: "GitHub からデプロイ", + upload: "ローカルコードからデプロイ", + workers: "バックグラウンドワーカー", + scaling: "スケーリング", + regions: "リージョン", + troubleshooting: "トラブルシューティング", +}; diff --git a/_locales/ja/deploy/github.mdx b/_locales/ja/deploy/github.mdx new file mode 100644 index 0000000..994e5e8 --- /dev/null +++ b/_locales/ja/deploy/github.mdx @@ -0,0 +1,100 @@ +--- +description: "GitHub リポジトリを接続すると、追跡対象ブランチへのすべての push でビルドと再デプロイが行われます。プライベートリポジトリ、ブランチ切り替え、モノレポにも対応しています。" +--- + + + +# GitHub からデプロイ + +GitHub リポジトリを接続することは、Lizard でアプリを実行するための推奨方法です。追跡対象ブランチへのすべての push で、自動的にビルドと再デプロイが行われます。 + + + +## リポジトリからサービスを作成する + +```bash +lizard add -r your-org/your-app +``` + +これにより `github`-source サービスが作成され、リポジトリがクローンされ、スタックが自動検出され（[lizardpack](/concepts/build-pipeline)）、ビルドされ、稼働中の URL が返されます。便利なフラグ: + +| フラグ | 目的 | +|------|---------| +| `-r, --repo ` | ソースリポジトリ | +| `-n, --name ` | サービス名（`${{name.KEY}}` 参照とダッシュボードで使用） | +| `-v, --variables ` | 環境変数を初期設定します。繰り返し指定可能 | +| `--region ` | デプロイ先のリージョン | +| `--no-deploy` | リポジトリを接続するが最初のビルドはスキップ | + + + +## プライベートリポジトリ + +プライベートリポジトリへのアクセスを許可するには、アカウントごとに一度 Lizard GitHub App を接続します: + +```bash +lizard git connect +lizard git status # show connection + repo status +``` + +ダッシュボードの **GitHub integration** ページ（`lizard open`）から、リポジトリへのアクセスを接続および管理することもできます。 + + + +## 既存のサービスをリポジトリに向ける + +サービスを git ソースに切り替える場合（またはリポジトリ/ブランチを変更する場合）: + +```bash +lizard service set api \ + --set sourceType=github \ + --set repoUrl=https://github.com/your-org/your-app \ + --set branch=main +``` + +ビルド項目を変更すると自動的に再ビルドされます。**その後に** `redeploy` **をつなげないでください**。 + +> **Note:** `lizard up` は常に `sourceType=upload` を強制します。git バックエンドのサービス更新には使わないでください。リモートへ push するか、代わりに `lizard redeploy` を使用してください。 + + + +## push 時に自動再デプロイ + +`repoUrl` が設定されると、一致する `branch` への push は GitHub webhook 経由で自動的に再デプロイされます。どの push が再デプロイをトリガーするかを絞り込むには: + +- **`rootDirectory`** — サブディレクトリのみをビルドします（モノレポ）。 +- **`watchPatterns`** — 一致するパスが変更された場合のみ再デプロイします。 + +```bash +lizard service set api --set watchPatterns='apps/api/**,packages/**' +``` + + + +## ブランチを切り替える + +```bash +lizard git checkout api staging # move the `api` service to the `staging` branch and redeploy +``` + + + +## モノレポ + +複数のアプリを含むリポジトリでは、アプリごとに 1 つのサービスを作成し、その `rootDirectory` をサブパスに設定します: + +```bash +lizard add -r your-org/monorepo -n api +lizard service set api --set rootDirectory=apps/api +``` + +現在のディレクトリが、親がすでにリンク済みのリポジトリ内のサブアプリである場合は、親のプロジェクト内にサービスを追加し、`rootDirectory` を cwd のサブパスに設定します。 + + + +## 関連項目 + +- [ビルド Pipeline](/concepts/build-pipeline) — スタックがどのように検出され、ビルドされるか。 +- [ローカルコードからデプロイする](/deploy/upload) — リモートがない場合。 +- [`lizard git`](/cli/git) — `connect`、`status`、`checkout` の完全なコマンドリファレンス。 +- [AI IDE が作成したアプリのデプロイ先](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#where-to-deploy-an-app-your-ai-ide-built) — エージェントが作成したリポジトリをこれに向ける方法と、そのコスト。 diff --git a/_locales/ja/deploy/index.mdx b/_locales/ja/deploy/index.mdx new file mode 100644 index 0000000..08f6f9a --- /dev/null +++ b/_locales/ja/deploy/index.mdx @@ -0,0 +1,22 @@ +--- +description: "Lizard でサービスを稼働させ、維持するためのすべて: GitHub とローカルからのデプロイ、ワーカー、スケーリング、リージョン、修正。" +--- + + + +# デプロイ + +Lizard でサービスを稼働させ、その状態を維持するためのすべて — 最初の push からスケーリングやリージョン配置まで。 + +まず別のホストと比較検討していますか？ ブログでは 9 つの [container as a service](https://lizard.build/blog/container-as-a-service) プラットフォームを並べて価格比較しています。 + + + +## このセクションについて + +- [GitHub からデプロイ](/deploy/github) — リポジトリを接続すると、追跡対象ブランチへの push で自動的に再デプロイされます。 +- [ローカルコードからデプロイ](/deploy/upload) — Git 不要で、現在のディレクトリを `lizard up` でデプロイします。 +- [バックグラウンドワーカー](/deploy/workers) — `containerPort=0` でキューコンシューマーやポーリングループを実行します。 +- [スケーリング](/deploy/scaling) — レプリカ、リソース、ストレージを調整します。 +- [リージョン](/deploy/regions) — サービスが実行される場所です。 +- [トラブルシューティング](/deploy/troubleshooting/incomplete-dockerfile) — よくあるビルドおよびデプロイの問題の修正方法です。 diff --git a/_locales/ja/deploy/regions.mdx b/_locales/ja/deploy/regions.mdx new file mode 100644 index 0000000..f2fe97b --- /dev/null +++ b/_locales/ja/deploy/regions.mdx @@ -0,0 +1,40 @@ +--- +description: "サービスとアドオンをどこで実行するかを選び、ステートフルなリソースを同じ場所に配置してレイテンシを下げ、リージョンが生成ドメインにどう影響するかを確認します。" +--- + + + +# リージョン + +サービスとアドオンはリージョンにプロビジョニングされます。アカウントで利用可能なリージョンを一覧し、作成時に 1 つ選択します。 + + + +## リージョンを一覧する + +```bash +lizard regions +lizard regions --json +``` + + + +## リージョンを選ぶ + +サービスまたはアドオンの作成時に `--region ` を渡します: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +リージョンを指定しない場合、プラットフォームはプロジェクトのデフォルトを使用します。 + +> **ステートフルなリソースは同じ場所に配置してください。** サービスと、それが通信するアドオン（Postgres、Redis、S3）は、レイテンシを低く保ち、リージョン間のデータ転送料金を避けるために、**同じリージョン** に配置してください。 + + + +## 生成ドメイン + +各サービスには、リージョンに関係なく、自動 TLS 付きで `*.onlizard.com` 上の生成ドメインが割り当てられます。[S3 addon](/addons/storage) から配信されるオブジェクトストレージは、リージョンごとのゲートウェイホスト（`s3-.onlizard.com`）を使用します。独自のホスト名を接続するには、[Networking](/networking) を参照してください。 diff --git a/_locales/ja/deploy/scaling.mdx b/_locales/ja/deploy/scaling.mdx new file mode 100644 index 0000000..355f638 --- /dev/null +++ b/_locales/ja/deploy/scaling.mdx @@ -0,0 +1,78 @@ +--- +description: "サービスのレプリカ追加や CPU・メモリ増強、アドオンストレージの拡張を行います。許可範囲、ロールアウトの動作、変更確認方法を説明します。" +--- + + + +# スケーリング + +`lizard scale` を使って、サービスを水平スケール（レプリカ追加）または垂直スケール（CPU/メモリ増強）できます。アドオンストレージも同じ方法で拡張します。 + + + +## サービスをスケールする + +```bash +lizard scale --service api --replicas 3 +lizard scale --service api --cpu 2 --memory 2048 +``` + +| フラグ | 適用対象 | 許可値 | +|------|-----------|----------------| +| `--replicas ` | apps | `1`–`10` | +| `--cpu ` | apps | whole cores: `1`, `2`, `3`, `4` | +| `--memory ` | apps | `128`–`8192` MB (1 MB 刻み) | +| `--storage ` | **addons only**, grow-only | `512`, `1024`, `2048`, `4096`, `8192`, `16384` | + +フラグは 1 つのコマンドで組み合わせて指定できます。レプリカの変更はリビルドなしでロールアウトされます。 + + + +## 水平スケーリング + +ロードバランサーの背後で、アプリの複数レプリカを実行します: + +```bash +lizard scale --service api --replicas 5 +``` + +各レプリカはそれぞれ独立した pod です。レプリカを相互に置き換え可能にするため、アプリはステートレスにしてください（状態は [Postgres](/addons/postgres)、[Redis](/addons/redis)、または [S3](/addons/storage) に保存します）。 + + + +## 垂直スケーリング + +単一レプリカにより多くのリソースを割り当てます: + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +## アドオンストレージの拡張 + +アドオンのデータボリュームは **拡張のみ可能** です。ストレージは増やせますが、縮小はできません: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## 確認 + +```bash +lizard ps # replica status + URL +lizard events # per-replica deploy/scale history +lizard metrics # live CPU / memory / network / disk +lizard metrics --cost # include cost +``` + + + +## 関連項目 + +- [オブザーバビリティ → Metrics](/observability/metrics) — リソースとコストの監視。 +- [`lizard scale`](/cli/scale) — 完全なコマンドリファレンス。 +- [2026年のCaaSプロバイダーの料金](https://lizard.build/blog/container-as-a-service#what-caas-providers-charge-in-2026) — スケール前に請求額を見積もれるよう、9 つのプラットフォームにおける vCPU 単価、GB 単価、エグレス料金を比較しています。 diff --git a/_locales/ja/deploy/troubleshooting/_meta.ts b/_locales/ja/deploy/troubleshooting/_meta.ts new file mode 100644 index 0000000..7de555e --- /dev/null +++ b/_locales/ja/deploy/troubleshooting/_meta.ts @@ -0,0 +1,5 @@ +export default { + 'incomplete-dockerfile': "Dockerfile の変更が反映されない", + 'double-build': "1 つの変更で 2 回のビルドがキューに入った", + 'service-never-healthy': "サービスが正常状態にならない", +}; diff --git a/_locales/ja/deploy/troubleshooting/double-build.mdx b/_locales/ja/deploy/troubleshooting/double-build.mdx new file mode 100644 index 0000000..9876b6d --- /dev/null +++ b/_locales/ja/deploy/troubleshooting/double-build.mdx @@ -0,0 +1,53 @@ +--- +description: "lizard service set の後に redeploy を実行すると 2 つのビルドがキューされる理由、自動で再ビルドされるフィールド、そして冗長な 1 つを防ぐ方法。" +--- + + + +# 変更によって 2 つのビルドが連続でキューされました + +フィールドを変更するために `lizard service set` を実行し、その後 `lizard redeploy` を実行した結果、1 つではなく 2 つのビルドになりました。 + + + +## これは何を意味するのか + +`service set` の呼び出しは、すでにそれ自体で再ビルドをトリガーしていました。続けて実行した `redeploy` により、2 つ目の冗長なビルドがキューされました。 + + + +## なぜこれが起こるのか + +サービスの **ビルドに影響する** フィールド — `repoUrl`、`branch`、`sourceType`、`buildCommand`、`dockerfilePath`、または `rootDirectory` — を変更すると、すぐに自動で再ビルドされます。**ランタイムのみ** のフィールド — `startCommand`、`preDeployCommand`、`containerPort`、`watchPatterns` — を変更しても、自動で再ビルドは **されません**。これは次回のデプロイ時にのみ反映されます。 + +`service set` のたびに反射的に `redeploy` を続けて実行しがちですが、それが意味を持つのはランタイムのみのフィールドに対してだけです。 + + + +## 考えられる解決策 + + + +### 変更したフィールドの種類を確認する + +[再ビルドのトリガー一覧表](/concepts/build-pipeline#what-triggers-a-rebuild)を参照してください。ビルドフィールドであれば、再ビルドはすでにキューされています。追加では何もしないでください。 + +```bash +lizard events # confirm only one build is in flight +``` + + + +### ランタイムのみの変更後にだけ redeploy する + +```bash +lizard service set api --set startCommand="node server.js" +lizard redeploy --service api # needed here — startCommand doesn't auto-rebuild +``` + + + +## 関連項目 + +- [ビルド Pipeline → 再ビルドをトリガーするもの](/concepts/build-pipeline#what-triggers-a-rebuild) +- [`lizard service`](/cli/service) — 完全なコマンドリファレンス。 diff --git a/_locales/ja/deploy/troubleshooting/incomplete-dockerfile.mdx b/_locales/ja/deploy/troubleshooting/incomplete-dockerfile.mdx new file mode 100644 index 0000000..3794b78 --- /dev/null +++ b/_locales/ja/deploy/troubleshooting/incomplete-dockerfile.mdx @@ -0,0 +1,57 @@ +--- +description: "ビルド手順のないリポジトリの Dockerfile を Lizard が置き換える理由、不完全な Dockerfile ルールの仕組み、そのまま使用させる方法。" +--- + + + +# Dockerfile の変更が反映されていないようです + +リポジトリに `Dockerfile` があり、それを編集したにもかかわらず、Lizard が実行するビルドがあなたの記述と一致しません。 + + + +## これは何を意味するのか + +プラットフォームは、リポジトリの Dockerfile が**不完全**だと判断し、あなたのものをそのまま使う代わりに [lizardpack](/concepts/build-pipeline) で再生成しました。 + + + +## なぜこれが起こるのか + +Lizard が lizardpack の自動検出パスでリポジトリの Dockerfile を**そのまま**使うのは、それに実際のビルド手順、つまり `RUN ` 行がある場合だけです。ビルド済みアーティファクトをコピーするだけの Dockerfile（`COPY dist/`、`build/`、`out/`、`.next/`、`public/`）で、`RUN` 手順がないものは、それらのアーティファクトがイメージの外部でビルドされたと見なされ、不完全として扱われます。その場合、lizardpack が不足しているビルド手順を含む置き換え用 Dockerfile を生成します。 + +これは lizardpack の自動検出パスでのみ適用されます。サービスに `buildCommand` または `startCommand` が設定されている場合、Lizard はそれらのコマンドから Dockerfile を合成し、リポジトリの Dockerfile はまったく参照しません。 + + + +## 考えられる解決策 + + + +### 実際のビルド手順を追加する + +Dockerfile をそのまま使いたい場合は、ビルド済み出力をコピーするのではなく、実際のビルド手順を追加してください。 + +```dockerfile +RUN npm ci && npm run build +``` + + + +### またはそのまま使用するよう強制する + +ビルドと起動のオーバーライドをクリアしてから、同じ更新で `dockerfilePath` を設定してください。オーバーライドはファイルパスよりも優先されます。 + +```bash +lizard service set api --set buildCommand=null --set startCommand=null --set dockerfilePath=Dockerfile +``` + + + +## 関連情報 + +- [ビルド Pipeline](/concepts/build-pipeline) — ビルドの判断順序の全体像。 +- [ビルド設定リファレンス](/concepts/build-pipeline#build-configuration-reference) +- [Lizard で任意の Python アプリをデプロイする](https://lizard.build/blog/python-app-hosting#deploying-any-python-app-on-lizard) — Dockerfile を lizardpack に書かせるべき場合と、自前のものを持ち込むべき場合。 + +これらのビルド項目を変更すると、ビルドが開始されることがあります。2 回目のビルドを開始しないよう、別の `redeploy` を送信する前に `lizard events` を確認してください。 diff --git a/_locales/ja/deploy/troubleshooting/service-never-healthy.mdx b/_locales/ja/deploy/troubleshooting/service-never-healthy.mdx new file mode 100644 index 0000000..2f5984f --- /dev/null +++ b/_locales/ja/deploy/troubleshooting/service-never-healthy.mdx @@ -0,0 +1,59 @@ +--- +description: "ビルドは成功するのに、デプロイが不健全なままです。ポートのバインド、意図しない worker mode、そのほかヘルスチェック失敗の原因。" +--- + + + +# サービスはデプロイされるのに、正常状態になりません + +ビルドは成功し、レプリカは起動しますが、デプロイは pending のままになるか、unhealthy とマークされるか、いつまでもトラフィックを受け取りません。 + + + +## これは何を意味するのか + +アプリのポートに到達できることを確認するプラットフォームのヘルスチェックが一度も通らないため、トラフィックが新しいレプリカに切り替わりません。 + + + +## なぜ起こるのか + +- **アプリが想定されたポートで listen していません。** Lizard は `PORT` 環境変数（デフォルトのコンテナポートは `3000`）を注入し、アプリがそこで到達可能かどうかを確認します。アプリが別のポートにハードコードされているか、まったくバインドしていない場合、ヘルスチェックは無期限に失敗します。よくあるのは Python アプリです: `gunicorn` と `uvicorn` は、特に指定しない限り `127.0.0.1` にバインドし、プローブはプロセスの外側から来ます。[Pythonアプリホスティング](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) には、各フレームワークで必要な `--bind 0.0.0.0:$PORT` の行があります。 +- **サービスが誤って worker mode になっています。** `containerPort=0` を設定すると、サービスは [worker mode](/deploy/workers) になり、**ヘルスチェックとロードバランサー登録の両方が完全にスキップされます**。HTTP を提供するはずのサービスが誤って `containerPort=0` に切り替えられると、デプロイは「成功」するものの何も配信せず、worker mode によって本来の起動問題が表面化せずに隠れてしまいます。 + + + +## 考えられる解決策 + + + +### 現在のポートを確認する + +```bash +lizard port --service api +``` + +これが `worker mode` を表示する場合、そのサービスには `containerPort=0` が設定されています。このサービスが HTTP を提供する想定なら、実際のポートに戻してください: + +```bash +lizard port 3000 --service api +lizard redeploy --service api +``` + + + +### アプリが Lizard の想定どおりの場所で listen していることを確認する + +起動エラーがないかランタイムログを確認し、アプリが実際にバインドしたポートと、Lizard が注入したポートが一致しているかを検証してください: + +```bash +lizard logs --service api +lizard ssh --service api -- env | grep PORT +``` + + + +## 関連項目 + +- [Background Workers](/deploy/workers) — `containerPort=0` が適切な場合と、そうでない場合。 +- [デプロイメント → lifecycle](/concepts/deployments#lifecycle) — デプロイの中でヘルスチェックがどこに位置するか。 diff --git a/_locales/ja/deploy/upload.mdx b/_locales/ja/deploy/upload.mdx new file mode 100644 index 0000000..39a6973 --- /dev/null +++ b/_locales/ja/deploy/upload.mdx @@ -0,0 +1,84 @@ +--- +description: "Git は不要で、lizard up を使って現在のディレクトリをデプロイします。.gitignore の扱い、build と start の上書き、ヘッドレス CI での利用について説明します。" +--- + + + +# ローカルコードからデプロイ + +コードが GitHub にない場合、または単にすばやく反復したい場合は、`lizard up` を使って現在のディレクトリを直接アップロードできます。作業ツリーを tarball としてパッケージ化し、ビルドノードに送信してデプロイします。 + + + +## 現在のディレクトリをデプロイ + +```bash +lizard up +``` + +- 現在のディレクトリを tarball としてアップロードし、`.gitignore` を尊重します（`--no-gitignore` で無効化）。 +- `sourceType=upload` を強制します。 +- SSE 経由でビルドログをストリーミングし、完了時にライブ URL を表示します。 + +ディレクトリがまだプロジェクトにリンクされていない場合、`up` は最初に `init` を実行します。TTY では対話的に動作しますが、非 TTY（CI）では空のプロジェクトを暗黙的に作成することは**ありません**。代わりにエラーになり、`lizard init --name ` を実行するよう求めます（または `--name` を渡します）。これは、タイプミスによって空のプロジェクトが作成されるのを防ぐためです。 + + + +## よく使うフラグ + +| フラグ | 目的 | +|------|---------| +| `-s, --service ` | 特定のサービスを対象にする／作成する | +| `--build-command ` | build コマンドを上書きする | +| `--start-command ` | start コマンドを上書きする | +| `--pre-deploy-command ` | 各デプロイ前に 1 回実行する（例: マイグレーション） | +| `--port ` | コンテナポート（`0` = [worker mode](/deploy/workers)） | +| `--region ` | デプロイ先のリージョン | +| `-d, --detach` | デプロイを開始して、ログをストリーミングせずに終了する | +| `-c, --ci` | CI 向けの出力 | +| `--no-gitignore` | `.gitignore` を無視してすべてをアップロードする | + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +## build/start コマンドの設定 + +`--build-command` または `--start-command` を渡すと、サービスは **synthesized Dockerfile** パスに切り替わります。このパスでは、`Procfile` と `package.json` `scripts.start` は読み取られ**ません**。start コマンドを明示的に設定してください（または独自の Dockerfile に `CMD` を含めてください）。詳しくは [ビルド Pipeline](/concepts/build-pipeline) を参照してください。特に影響を受けやすいのは Python です。[Django, Flask and FastAPI](https://lizard.build/blog/python-app-hosting#deploying-django) では、それぞれ異なる `gunicorn` または `uvicorn` の行が必要です。 + + + +## アップロードサービスを再デプロイする + +`lizard up` は再アップロードして再ビルドします。再アップロードせずに、現在の変数で**前回**のアップロードを再ビルドするには: + +```bash +lizard redeploy --service api +``` + + + +## ヘッドレス / CI + +非対話フローでは、デプロイ前に明示的にプロジェクトをリンクしてください: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +## 代わりに GitHub を使うべき場合 + +アップロードは、すばやい反復やリモートがない状況に最適です。長期的に運用するものについては、プッシュ時に自動で再デプロイされ、クリーンなデプロイ履歴も得られるため、[GitHub source](/deploy/github) を使うことをおすすめします。 + + + +## 関連項目 + +- [`lizard up`](/cli/up) — 完全なコマンドリファレンス。 +- [ビルド Pipeline](/concepts/build-pipeline) — スタックがどのように検出され、ビルドされるか。 diff --git a/_locales/ja/deploy/workers.mdx b/_locales/ja/deploy/workers.mdx new file mode 100644 index 0000000..9b875c9 --- /dev/null +++ b/_locales/ja/deploy/workers.mdx @@ -0,0 +1,124 @@ +--- +description: "HTTPポートなしでキューコンシューマーとポーリングループを実行します。containerPort=0 で何が変わるか、有効化方法、そして使うべきでない場合を説明します。" +--- + + + +# バックグラウンドワーカー + +すべてのサービスが HTTP を提供するわけではありません。キューコンシューマー、reconciler、cron 風のポーリングループ、その他のバックグラウンドワークロードはポートを listen しません。コンテナポートを `0` に設定して、**worker mode** で実行してください。 + + + +## worker mode で変わること + +`containerPort=0` の場合、プラットフォームは次のように動作します: + +- **`PORT` injection をスキップ** — ワーカーはどこにも bind しません。 +- **ポート到達性チェックをスキップ** — `app port X unreachable` のログスパムや、誤検知の "unhealthy" ステータスは発生しません。 +- 合成された Dockerfile の **`EXPOSE`** をスキップ。 +- **ロードバランサーのルート登録をスキップ** — 何も配信されません。（生成された `*.onlizard.com` ドメインがサービス上に表示される場合はありますが、応答しません。） + + + +## worker mode を有効にする + +同等の方法が 3 つあります: + +```bash +# New upload-source worker +lizard up --port 0 + +# Flip an existing service +lizard port 0 --service worker + +# Via the config:apply path +lizard service set worker --set containerPort=0 +``` + +worker mode は完全な切り替えです。ポート変更を反映するには再デプロイが必要です。 + + + +## 現在のポートを確認する + +```bash +lizard port --service worker +``` + +現在のコンテナポート、またはそれが `0` の場合は `worker mode` を表示します。 + + + +## worker mode を使うべきでない場合 + +起動が遅いだけの通常の HTTP サービスには worker mode を使わないでください。worker mode は到達性チェックを完全に無効化するため、**「リスナーが起動しなかった」** バグを隠してしまいます。サービスがトラフィックを処理する想定なら、実際のポートを維持し、代わりに起動処理を修正してください。 + + + +## キューコンシューマーを実行する + +[redis-workerの例](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/redis-worker) を使います。これはジョブを pending リストから processing リストへ移動し、その大文字化した結果を保存し、Redis トランザクションでジョブを確認済みにします。レプリカは 1 つのままにしてください。起動時の復旧は単一コンシューマーを前提にしています。この例は Python 3.13 と redis-py 6.4.0 を使います。 + +その Dockerfile を含むディレクトリから実行します: + +```bash +lizard init --name queue-example +lizard add --service worker +lizard add redis +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +lizard up --service worker --port 0 +``` + +コマンドで認証が必要と表示されたら、`lizard login` でサインインしてください。データベースの実際の名前が `redis` でない場合は、その名前を使用してください。参照は引用符で囲んだままにしてください。アプリケーションをアップロードする前に設定します。macOS で Lizard CLI 0.3.92 を使う場合、AppleDouble metadata を除外するには `lizard up` の前に `COPYFILE_DISABLE=1` を付けてください。 + +最後のデプロイイベントを確認し、その後ワーカーを確認します: + +```bash +lizard port --service worker +lizard logs --service worker --json +lizard ssh --service worker -- python jobs.py enqueue first-job +lizard ssh --service worker -- python jobs.py result first-job +``` + +プロセスは `Queue worker ready` を出力します。ログの tail が空でも、下のジョブ確認に進んでください。[test results](/guides/validation) に観測されたロギング制限が記録されています。結果確認コマンドは最大 30 秒待機し、`{"id": "first-job", "result": "HELLO"}` を表示します。プロセスが動作中であることだけでは、ジョブを消費できる証明にはなりません。Managed Redis にはサービス内部から到達します。CLI コマンドでは、あなたの laptop からその private address に到達できる必要はありません。 + + + +## 再起動を検証する + +このテストサービスでは、ワーカーを再起動して別のジョブを送信します: + +```bash +lizard restart --service worker +lizard ssh --service worker -- python jobs.py result first-job +lizard ssh --service worker -- python jobs.py enqueue after-restart +lizard ssh --service worker -- python jobs.py result after-restart +``` + +SSH がまだ使えない場合は、`lizard ps --json` でサービスが `running` に戻るまで待ってください。両方の結果は `HELLO` になるはずです。最初の結果は Redis に保存されるため、ワーカーを再起動しても削除されません。起動時に単一コンシューマーは未完了の processing エントリを pending リストに戻します。 + +このデモは `jobs.py` が作成した JSON ジョブのみを受け付けます。dead-letter queue、信頼できない producer 向けのバリデーション、または external side effects の exactly-once は実装していません。支払い、メール、その他の副作用には、実績のあるキューライブラリと冪等なハンドラーを使用してください。Redis の永続性とバックアップは、ワーカー再起動時の挙動とは別です。[ストレージとリカバリ](/platform/storage-and-recovery) を参照してください。 + + + +## トラブルシューティング + +| 症状 | 確認 | +|---|---| +| サービスが見つからない | プロジェクト作成後に `lizard add --service worker` を実行してください。 | +| `Queue worker ready` がない | サービススコープの `REDIS_URL`、addon の準備完了状態、接続エラーを確認してください。接続文字列は絶対に表示しないでください。 | +| ワーカーが HTTP ポートを想定している | `containerPort=0` を設定してください。実行中サービスでこれを変更するには再デプロイが必要です。 | +| 30 秒後も結果がない | ワーカーログを読み、ジョブ ID を確認してください。この例は自身の `jobs.py` からのジョブのみ受け付けます。 | +| 副作用が重複する | リトライにより処理が再実行されることがあります。この例は結果をジョブ ID ごとに保存します。external effects には独自の冪等性が必要です。 | + + + +## 関連項目 + +- [`lizard port`](/cli/port) — サービスのコンテナポートを表示または変更します。 +- [サービスがヘルシー状態にならない](/deploy/troubleshooting/service-never-healthy) — worker-mode で最もよくある設定ミスです。 +- [Managed Addons](/addons) — ステートフルなワークロード向けの Redis、Postgres、S3。 +- [Pythonアプリホスティング](https://lizard.build/blog/python-app-hosting#deploying-django) — Celery ワーカーは、コマンドだけが異なり HTTP ポートがない同じイメージです。 + +確認済みバージョン、クラウドでの結果、残っている制限については、[シナリオテストの結果](/guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/_meta.ts b/_locales/ja/framework-guides/_meta.ts new file mode 100644 index 0000000..c0d6fc9 --- /dev/null +++ b/_locales/ja/framework-guides/_meta.ts @@ -0,0 +1,16 @@ +export default { + index: "概要", + nextjs: { title: "Next.js", display: "children" }, + react: "React (Vite)", + vue: "Vue (Vite)", + astro: "Astro", + nuxt: "Nuxt", + sveltekit: "SvelteKit", + fastapi: "FastAPI", + django: "Django", + docusaurus: "Docusaurus", + vitepress: "VitePress", + hugo: "Hugo", + 'static-routing': "静的ルートと404", + validation: "テスト済みのバージョンと結果", +}; diff --git a/_locales/ja/framework-guides/astro.mdx b/_locales/ja/framework-guides/astro.mdx new file mode 100644 index 0000000..67faa78 --- /dev/null +++ b/_locales/ja/framework-guides/astro.mdx @@ -0,0 +1,98 @@ +--- +description: "Astro を Lizard に静的サイトとして、または standalone Node adapter とともにデプロイします。サーバールートや見つからないページのために、output、build コマンド、ポート、チェックを設定します。" +--- + + + +# Astro を Lizard にデプロイする + +Astro には Lizard 上で 2 つのデプロイ方法があります: ポート `80` で静的な `dist/` ディレクトリを配信するか、オンデマンドルートのためにポート `3000` で standalone Node adapter を実行します。adapter は output と runtime の両方を変更するため、デプロイ前にモードを選んでください。 + + + +## モードを選ぶ + +| モード | 設定 | ランタイム | ポート | +|---|---|---|---| +| 静的サイト | サーバー adapter を使わない静的 output | nginx が `dist/` を配信 | `80` | +| Node サーバー | standalone モードの `@astrojs/node` | `node ./dist/server/entry.mjs` | `3000` | + +どちらの方法でも、`astro build` を実行する `build` スクリプトを使います。lockfile をコミットし、デフォルトの `dist` output path を維持してください。検出は Astro の config とインストール済みの依存関係を読み取ります。未使用の Node adapter dependency だけではサーバーパスは選択されません。リテラルな `output` と adapter 設定を使ってください。動的な値、カスタム output path、middleware モードでは Dockerfile が必要です。 + + + +## Node サーバーを設定する + +オンデマンドページでは、Astro のバージョンと互換性のある Node adapter のバージョンを追加します: + +```bash +npx astro add node +``` + +`astro.config.mjs` を確認します: + +```js +import { defineConfig } from 'astro/config'; +import node from '@astrojs/node'; + +export default defineConfig({ + output: 'server', + adapter: node({ mode: 'standalone' }), +}); +``` + +Standalone モードは独自の HTTP サーバーを起動します。Middleware モードには別のサーバーが必要であり、この起動コマンドには適していません。middleware や prerendered ルートとオンデマンドルートの組み合わせが必要な場合は、[Astro Node アダプタ ガイド](https://docs.astro.build/en/guides/integrations-guide/node/) を読んでください。 + + + +## ローカルでテストする + +```bash +npm ci +npm run build +``` + +Node モードの場合: + +```bash +HOST=0.0.0.0 PORT=3000 node ./dist/server/entry.mjs +``` + +実際にサーバー上で実行されるルートと、ビルド済みアセットをリクエストしてください。静的サイトでは、ローカルで `npm run preview` を使い、`dist/` 内の生成されたルートファイルを確認してください。 + + + +## デプロイする + +[CLI setup](/framework-guides#prepare-the-project) の後、プロジェクトを作成します: + +```bash +lizard init --name astro-app +lizard add --service web +``` + +Node adapter の場合: + +```bash +lizard up --service web --port 3000 +``` + +静的サイトの場合: + +```bash +lizard up --service web --port 80 +``` + +選んだモードに対応するコマンドだけを使ってください。lizardpack 検出のために、service command overrides は未設定のままにしてください。`lizard logs --build --service web --json` を読み、その後 runtime logs と live URL を確認してください。 + + + +## 変数、sessions、routes + +静的 HTML の生成に使われる値は、変更時に新しい build が必要です。サーバーコードは、Astro のバージョンでサポートされる仕組みを通じて runtime variables を読み取れます。[変数とシークレット](/variables) で設定してください。ブラウザから見える値には credentials を含めてはいけません。 + +アプリで sessions を使う場合は、再起動や複数レプリカに適したストレージを選んでください。container filesystem を共有可能で永続的なストアとして当てにしないでください。[ストレージとリカバリ](/platform/storage-and-recovery) を参照してください。 + +静的コンテンツサイトでは、存在しない URL をテストし、適切な status を返すために [静的ルートと404エラー](/framework-guides/static-routing) を使ってください。SSR デプロイが終了する、またはどのルートも配信しない場合は、`dist/server/entry.mjs` が存在すること、adapter が standalone モードを使っていること、service port が `3000` であることを確認してください。 + +2026 年 9 月 9 日のデプロイチェックとその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/django.mdx b/_locales/ja/framework-guides/django.mdx new file mode 100644 index 0000000..41a6d0e --- /dev/null +++ b/_locales/ja/framework-guides/django.mdx @@ -0,0 +1,221 @@ +--- +description: "Gunicorn、明示的な WSGI モジュール、port 8000、本番設定、データベースマイグレーション、静的ファイルとアップロードファイルの方針を使って、Lizard に Django をデプロイします。" +--- + + + +# Lizard に Django をデプロイする + +Gunicorn と、プロジェクトの WSGI モジュールを port `8000` で使って、Lizard 上で Django を実行します。デプロイしたアプリを運用に使う前に、本番設定、データベースアクセス、静的ファイル配信を準備してください。`manage.py runserver` は開発サーバーです。 + + + +## 起動コマンドを設定する + +このガイドでは、`manage.py`、`requirements.txt`、そして `config` を含む `wsgi.py` というプロジェクトパッケージ名を前提としています。`config` は実際のパッケージ名に置き換えてください。 + +テスト済みの requirements に、Django、Gunicorn、そしてアプリが使うデータベースドライバーを含めてください。`Procfile` を追加します: + +```text +web: gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +設定がネストしたパッケージ内にある場合、この明示的なモジュール指定により曖昧さを避けられます。WebSockets を使う ASGI アプリには ASGI サーバーと別の起動コマンドが必要です。このガイドは WSGI を対象としています。 + +| 設定 | 値 | +|---|---| +| Install | `pip install -r requirements.txt` | +| ランタイム | WSGI モジュールを使う Gunicorn | +| サービスポート | `8000` | +| Working directory | `manage.py` を含むディレクトリ | + + + +## 本番設定を準備する + +Django は `settings.py` 内に `DATABASES` 辞書があることを前提としています。サービスで `DATABASE_URL` だけを設定しても、Django は PostgreSQL に接続しません。以下の手順では、[Managed Postgres](/addons/postgres) を作成し、その URL をアプリに渡し、その URL を Django の接続設定に変換します。 + +`requirements.txt` に以下のパッケージを追加してください。アプリに必要なほかの依存関係はそのまま維持します。これらは [完全な例](https://github.com/lizard-build/docs/tree/main/_examples/django) で使っているバージョンです: + +```text +Django==6.1.1 +gunicorn==26.2.0 +whitenoise==6.12.0 +psycopg[binary]==3.3.5 +dj-database-url==3.1.2 +``` + +`psycopg` は PostgreSQL ドライバーです。`dj-database-url` は接続 URL からデータベース名、ユーザー、パスワード、ホスト、port を読み取ります。プロジェクトの `settings.py` 内で対応する設定をこのブロックに置き換えてください。既存の apps、middleware、templates、そのほかの設定はそのまま維持します: + +```python +import os +from pathlib import Path + +import dj_database_url +from django.core.exceptions import ImproperlyConfigured + +BASE_DIR = Path(__file__).resolve().parent.parent + + +def required_env(name): + value = os.environ.get(name, "").strip() + if not value: + raise ImproperlyConfigured(f"Set the {name} environment variable.") + return value + + +def env_list(name): + values = [item.strip() for item in required_env(name).split(",") if item.strip()] + if not values: + raise ImproperlyConfigured(f"Set at least one value in {name}.") + return values + + +SECRET_KEY = required_env("SECRET_KEY") +debug_value = os.environ.get("DEBUG", "false").strip().lower() +if debug_value not in {"true", "false"}: + raise ImproperlyConfigured("DEBUG must be true or false.") +DEBUG = debug_value == "true" +ALLOWED_HOSTS = env_list("ALLOWED_HOSTS") +CSRF_TRUSTED_ORIGINS = env_list("CSRF_TRUSTED_ORIGINS") +DATABASES = { + "default": dj_database_url.parse( + required_env("DATABASE_URL"), + conn_max_age=60, + conn_health_checks=True, + ) +} +``` + +ファイルの後ろに古い `DATABASES`、`SECRET_KEY`、または `DEBUG` の代入を残さないでください。残っていると、これらの値が上書きされます。この例では、`SECRET_KEY`、`DATABASE_URL`、`ALLOWED_HOSTS`、`CSRF_TRUSTED_ORIGINS` に空でない値が必要です。値がない、または空の場合、起動はその変数名を表示して停止します。`DEBUG` のデフォルトは `false` です。デプロイしたサービスでは `false` に設定してください。 + +`ALLOWED_HOSTS` には、`app.example.com,www.example.com` のように、scheme や path を含まないカンマ区切りのホスト名を指定します。`CSRF_TRUSTED_ORIGINS` には、`https://app.example.com` のように、scheme を含むカンマ区切りの origin を指定します。ローカル origin が port を使う場合は、それも含めてください。この例では明示的な origin リストが必要です。Django 自体は、追加の trusted origins を必要としないアプリであれば空のリストも許可します。このアプリにフォーム送信してよい origin だけを trust してください。これらの設定は CSRF トークンの代わりにはなりません。 + +この URL は、ソースにコミットされた値ではなく、サービスの [secret または reference](/variables) から取得します。デプロイしたアプリの永続データベースとして、コンテナローカルの SQLite を使わないでください。URL の解析と接続オプションについては、[dj-database-urlの使用](https://pypi.org/project/dj-database-url/) を参照してください。 + +ローカル環境変数を設定し、PostgreSQL に到達できる状態で、次を実行します: + +```bash +python -m pip install -r requirements.txt +python manage.py check --deploy +gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +アプリに関連する設定については、Django の [deployment checklist](https://docs.djangoproject.com/en/6.1/howto/deployment/checklist/) を確認してください。この小さな例では、本番用のすべてのセキュリティ設定を構成していません。secure cookies、HSTS、redirects を有効にする前に、実際の公開 URL で proxy と HTTPS の扱いを確認してください。転送された HTTPS ヘッダーは、proxy がそれを制御している場合にだけ trust してください。 + + + +## 静的ファイルとマイグレーションを計画する + +Gunicorn 単体では Django の静的ファイルは配信されません。アプリ内で設定した静的ファイル用 middleware を使うか、別の静的ホストを選んでください。asset は、その構成が配信する path に collect してください。lizardpack の requirements ベースの Python path は `collectstatic` を自動実行しません。アプリでその手順が必要なら、完全な Dockerfile build に含めてください。 + +WhiteNoise を使う場合は、`INSTALLED_APPS` に `django.contrib.staticfiles` を維持し、Django の `SecurityMiddleware` の直後に `whitenoise.middleware.WhiteNoiseMiddleware` を挿入してください。以下の設定を追加または更新します: + +```python +STATIC_URL = "/static/" +STATIC_ROOT = BASE_DIR / "staticfiles" +STORAGES = { + "default": {"BACKEND": "django.core.files.storage.FileSystemStorage"}, + "staticfiles": { + "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage", + }, +} +``` + +アプリがすでに別の場所に uploads を保存しているなら、既存の `STORAGES["default"]` backend はそのまま維持してください。WhiteNoise が配信するのは collect 済みの静的 asset であり、ユーザー uploads ではありません。 + +プロジェクトルートにこの Dockerfile を使います: + +```dockerfile +FROM python:3.13-slim +WORKDIR /app +COPY requirements.txt ./ +RUN pip install --no-cache-dir -r requirements.txt +COPY . . +RUN SECRET_KEY=build-only-placeholder \ + DATABASE_URL=postgresql://build:build@127.0.0.1:1/build \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + python manage.py collectstatic --noinput +EXPOSE 8000 +CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"] +``` + +`RUN` 行の値は、`collectstatic` のためだけに存在します。データベース URL は未使用のローカル port を指すプレースホルダーで、その場所ではデータベースは動作していません。settings の読み込みでは URL が解析されますが、asset collection にデータベース接続は不要です。モジュール import や `AppConfig.ready()` からデータベースを問い合わせないでください。この例では、コンテナネットワークを無効にした状態で `collectstatic` も渡しています。 + +これらの代入は実行時環境変数にはなりません。起動前に、サービス上で新しい `SECRET_KEY` と実際のデータベース reference を設定してください。本番 secrets を Docker build に渡さないでください。 + +`.dockerignore` を作成し、同じ path を [source uploads](/cli/up) からも除外してください: + +```text +.env* +.venv/ +venv/ +.git/ +__pycache__/ +*.pyc +*.sqlite3 +staticfiles/ +``` + +ユーザー uploads は、コンテナの静的ディレクトリではなく、[Managed Object Storage](/addons/storage) のような永続ストレージに保持してください。[ストレージとリカバリ](/platform/storage-and-recovery) を確認してください。 + +データベースマイグレーションは別個のリリース手順として扱ってください。必要に応じてデータをバックアップし、マイグレーションは再試行しても安全になるようにし、新しい schema がリクエストで必要になる前に適用してください。pre-deploy command は、並行実行性や障害時の挙動を確認する代わりにはなりません。 + + + +## デプロイして確認する + +[CLI setup](/framework-guides#prepare-the-project) の後、[GitHub service](/deploy/github) を接続し、その secrets と本番設定を構成して、コンテナ port `8000` でデプロイしてください。新しい upload ベースのプロジェクトの場合: + +```bash +lizard init --name django-app +lizard add --service web +``` + +このプロジェクト内に [Managed Postgres](/addons/postgres) を作成します。すでにインスタンスがある場合は、`add postgres` をスキップして、その名前を reference で使ってください: + +```bash +lizard add postgres --name postgres +``` + +アプリの [service secrets](/cli/secrets) を設定します。`${{postgres.DATABASE_URL}}` 内の `postgres` は、Django のデータベース alias ではなく、データベースサービス名を表します。Lizard はデプロイ時に [reference](/variables/references) を解決し、得られた URL を `web` process に注入します。単一引用符は、shell がその reference を展開しないようにするためです。上の `settings.py` ブロックが、その URL を `DATABASES["default"]` に変換します。 + +```bash +DJANGO_SECRET_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(48))')" +lizard secrets set SECRET_KEY="$DJANGO_SECRET_KEY" \ + DATABASE_URL='${{postgres.DATABASE_URL}}' DEBUG=false \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + --service web +lizard up --service web --port 8000 +lizard ps --json +``` + +`localhost` は一時的な host 設定で、公開 hostname を取得するまで process を起動できるようにするものです。公開リクエストは 400 を返します。すでに hostname がわかっている場合は、最初の upload 前に設定してください。そうでない場合は、これらのプレースホルダーを、サービスに対して返された hostname と HTTPS origin に置き換えてください: + +```bash +lizard secrets set ALLOWED_HOSTS=YOUR_PUBLIC_HOST \ + CSRF_TRUSTED_ORIGINS=https://YOUR_PUBLIC_HOST --service web +``` + +reference の対象または key が見つからないと、空文字列に解決されることがあります。その場合、必須値チェックにより Django は `Set the DATABASE_URL environment variable.` で停止します。データベースサービス名と、その `DATABASE_URL` key を確認してください。接続 URL を logs に出力しないでください。 + +変数変更により process は再起動されます。ローカル virtual environments、secrets、ローカルデータベースは uploads から除外してください。process が動作したら、マイグレーションを適用します: + +```bash +lizard ssh --service web -- python manage.py migrate --noinput +``` + +マイグレーションが残っていないことを確認するために、もう一度コマンドを実行してください。port check が成功したことを、tables が存在する証拠と見なさないでください。 + +アプリ URL、データベースを使うページ、フォーム送信、静的 asset を確認してください。アプリが Django admin を使う場合は、その CSS も確認してください。import または settings のエラーについては `lizard logs --service web --json` を読んでください。400 レスポンスは `ALLOWED_HOSTS` が間違っていることを意味する場合がよくあります。CSS が欠けている場合は、通常、静的 asset が collect されていないか配信されていません。設定を変更する前に、実際のエラーを確認してください。 + +2026 年 9 月 9 日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 + + + + +## この例を再現する + +[Django example](https://github.com/lizard-build/docs/tree/main/_examples/django) には、settings、Dockerfile、requirements、データベースを使うフォーム、テストランナーが含まれています。これを独立したディレクトリにコピーし、Docker を起動した状態で `python3 tests/verify.py` を実行してください。image を build し、ローカル PostgreSQL を起動し、マイグレーションと HTTP の挙動を確認し、テスト用コンテナを停止します。Lizard のサービスは作成しません。確認項目と保持される Docker リソースについては、その README を参照してください。 + +2026 年 9 月 14 日の確認では、この改訂版の例をローカル Linux コンテナで扱っています。前述の cloud results は 9 月 9 日のガイドを対象としており、改訂後の settings はまだ新たな cloud デプロイを行っていません。 diff --git a/_locales/ja/framework-guides/docusaurus.mdx b/_locales/ja/framework-guides/docusaurus.mdx new file mode 100644 index 0000000..fca1255 --- /dev/null +++ b/_locales/ja/framework-guides/docusaurus.mdx @@ -0,0 +1,88 @@ +--- +description: "Docusaurus を Lizard 上の静的ドキュメントサイトとしてデプロイします。build ディレクトリをビルドし、URL と baseUrl を設定し、port 80 を使い、直接ルートと実際の 404 を確認します。" +--- + + + +# Lizard で Docusaurus をデプロイする + +Lizard で Docusaurus をビルドし、生成された `build/` ディレクトリを nginx 経由で port `80` で配信します。本番デプロイは静的ファイルを配信します。`docusaurus start` 開発サーバーは実行しません。 + +このレシピで使う設定とファイルを含む[完全なソース例](https://github.com/lizard-build/docs/tree/main/_examples/docusaurus)から始めてください。 + + + +## サイトを準備する + +`package.json`、その lockfile、および `docusaurus.config.*` を含む Docusaurus ディレクトリから実行します。依存関係には `@docusaurus/core` を残し、`docusaurus build` を実行する build スクリプトを用意してください。 + +| 設定 | 値 | +|---|---| +| ビルド | `npm run build` | +| Output | `build/` | +| ランタイム | nginx | +| サービスポート | `80` | + +Docusaurus の設定で、`url` にはサイトが公開される想定の origin を、`baseUrl` には実行されるパスを設定します。ドメインのルートにあるサイトでは、`baseUrl` は `/` です。最終的なホスト名が決まったら、そのホスト名で再ビルドし、生成される canonical URL と sitemap のエントリがそれを使うようにしてください。 + +末尾スラッシュの方針を一貫させ、生成されるファイルを確認してください。カスタムディレクトリをコピーする Dockerfile を用意しない限り、デフォルトの出力ディレクトリを維持してください。[Docusaurusデプロイガイド](https://docusaurus.io/docs/deployment) では、これらのフレームワーク設定を説明しています。 + + + +## ローカルでビルドして確認する + +```bash +npm ci +npm run build +npm run serve +``` + +最後のコマンドは、プロジェクトに scaffold の `serve` スクリプトがあることを前提にしています。トップページ、ネストされたドキュメントページ、画像、および docs のバージョンを使っている場合はバージョン付きページを確認してください。デプロイ前に、ビルドで報告された壊れたリンクを修正してください。 + + + +## デプロイ + +[CLI setup](/framework-guides#prepare-the-project) の後: + +```bash +lizard init --name docusaurus-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +生成されたホスト名を使う場合は、最初のデプロイ後にそれを読み取ります: + +```bash +lizard service show web --json +``` + +そのホスト名を使うように、`docusaurus.config.js` で `url` を設定します: + +```js +url: 'https://YOUR_PUBLIC_HOST', +``` + +build が公開 URL を使うように、変更した設定をアップロードします: + +```bash +lizard up --service web --port 80 +``` + + +ソース、プラグイン、設定、および lockfile をコミットしてください。`node_modules/`、`build/`、`.docusaurus/`、および `.env` ファイルはアップロード対象から除外してください。Docusaurus の検出パスを使うために、service command override は未設定のままにしてください。 + + + +## 内部ルートと存在しないページを配信する + +新しい Docusaurus の build は生成されたルートファイルを配信し、不明なパスには HTTP 404 を返します。このルーティング方針のためにカスタム Dockerfile は不要です。サービスがまだ 2026 年 9 月のルーティング修正前にビルドされたイメージを使っている場合は、再ビルドしてください。nginx の動作をカスタマイズする必要がある場合にのみ、[静的ルートと404エラー](/framework-guides/static-routing) を使ってください。 + +デプロイ後、ネストされた docs URL に直接リクエストし、再読み込みし、でっち上げた URL のステータスを確認してください。あわせて、最終的なホスト名で canonical URL と sitemap も確認してください。HTTP 200 のまま表示されるエラーページは、依然として soft 404 です。 + +アセットが見つからない場合は、その URL を `baseUrl` と比較してください。内部ルートがトップページを返す場合は、生成されたファイルレイアウトと nginx ルールを確認してください。環境値または Markdown ファイルを編集した後も古い内容が残る場合は、新しい build が実際に完了したことを確認してください。静的 HTML は build でのみ変更されます。 + +2026 年 9 月 9 日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 + diff --git a/_locales/ja/framework-guides/fastapi.mdx b/_locales/ja/framework-guides/fastapi.mdx new file mode 100644 index 0000000..1277522 --- /dev/null +++ b/_locales/ja/framework-guides/fastapi.mdx @@ -0,0 +1,98 @@ +--- +description: "Uvicorn、requirements.txt、Procfile、ポート 8000 を使って Lizard に FastAPI をデプロイします。ヘルスエンドポイントを確認し、import、host、依存関係のエラーを診断します。" +--- + + + +# Lizard に FastAPI をデプロイする + +Uvicorn が `0.0.0.0:8000` で待ち受けるようにして、Lizard で FastAPI を実行します。アプリの依存関係には FastAPI と Uvicorn の両方を含めてください。`app = FastAPI()` を宣言するファイルを import するだけでは、HTTP サーバーは起動しません。 + + + +## プロジェクト例 + +[FastAPI example](https://github.com/lizard-build/fastapi-example) には、アプリ、Procfile、固定された依存関係、MIT ライセンス、HTTP テストが含まれています。その CI は Linux 上で本番用の Uvicorn エントリポイントを実行します。GitHub からコミット `df522c1` もデプロイし、2026-09-09 に公開 HTTPS 経由でヘルス、OpenAPI、対話型ドキュメント、JSON エコー、不正な入力、存在しないルートを確認しました。 + + + +## アプリを準備する + +この例では、`requirements.txt` と、アプリケーションルートにある `main.py` を使用します: + +```python +from fastapi import FastAPI + +app = FastAPI() + +@app.get("/health") +def health(): + return {"status": "ok"} +``` + +`fastapi` と `uvicorn` を依存関係のワークフローに追加し、解決済みでテスト済みのバージョンを `requirements.txt` に保存します。依存関係が対応している場合は、`.python-version` で Python のマイナーバージョンを選択します。たとえば `3.13` です。 + +明示的な import ターゲットを持つ `Procfile` を作成します: + +```text +web: uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +`main:app` は、`main.py` 内の `app` オブジェクトを意味します。`src/api.py` には、`src.api:app` のように、アプリルートから動作する import パスを使用してください。明示的な Procfile により、カスタムレイアウトでのソースコードパターン検出への依存を避けられます。 + +| 設定 | 値 | +|---|---| +| Install | `pip install -r requirements.txt` | +| Start | Procfile `web:` command | +| サービスポート | `8000` | +| ビルド output | Pythonソースとインストール済み依存関係 | + + + +## ローカルでテストする + +ローカルの仮想環境を使用します: + +```bash +python -m venv .venv +source .venv/bin/activate +pip install -r requirements.txt +uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +別のターミナルで: + +```bash +curl --fail http://localhost:8000/health +``` + +`{"status":"ok"}` を含む正常なレスポンスを期待してください。開発中はリロードモードを維持します。[FastAPIサーバーガイド](https://fastapi.tiangolo.com/deployment/manually/) では、ASGI サーバーと import ターゲットについて説明しています。 + + + +## デプロイ + +[CLI setup](/framework-guides#prepare-the-project) の後、アプリケーションルートからアップロードします: + +```bash +lizard init --name fastapi-app +lizard add --service api +lizard up --service api --port 8000 +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +`.venv/`、`__pycache__/`、`.env` のファイルは除外してください。サービスの build/start オーバーライドは未設定のままにして、lizardpack が Procfile を読み取るようにします。ここでの requirements ベースの経路では、別個の compile コマンドは不要です。 + +返された HTTPS URL で `/health` をリクエストし、その後に実際の API アクションをテストします。TCP ヘルスプローブで確認できるのは、そのプロセスがポートを開いていることだけです。ヘルスエンドポイントには、アプリにとって重要なチェックを追加できます。 + + + +## データとよくある障害 + +認証情報は [変数とシークレット](/variables) を通じて設定します。アプリがデータベースを必要とする場合は [Managed Postgres](/addons/postgres) を追加し、サービススコープの接続参照を使用してください。コンテナローカルのファイルは永続的なアプリケーションストレージではありません。[ストレージとリカバリ](/platform/storage-and-recovery) を参照してください。 + +`No module named uvicorn` の場合は、インストールされた requirements を確認してください。ASGI の import エラーについては、同じルートから正確な Procfile コマンドをローカルで実行します。サービスがいつまでも healthy にならない場合は、ポート `8000` と bind host を確認してください。サーバーログがないままプロセスが終了する場合は、Uvicorn ではなく単に `python main.py` を実行していないか確認してください。 + +2026 年 9 月 9 日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/hugo.mdx b/_locales/ja/framework-guides/hugo.mdx new file mode 100644 index 0000000..d904f24 --- /dev/null +++ b/_locales/ja/framework-guides/hugo.mdx @@ -0,0 +1,89 @@ +--- +description: "Lizard で Hugo をデプロイするには、hugo --minify で public をビルドし、port 80 の nginx で配信します。検出、テーマ、baseURL、生成されたルート、欠落ページのステータスを確認します。" +--- + + + +# Lizard で Hugo をデプロイする + +Lizard は、`hugo --minify` で Hugo のソースサイトをビルドし、`public/` を nginx 経由で port `80` で配信できます。生成済み HTML だけをアップロードするのではなく、Hugo の設定と `content/` を含む Hugo のソースディレクトリから開始してください。 + +この手順で使われている設定とファイルを含む、[完全なソース例](https://github.com/lizard-build/docs/tree/main/_examples/hugo)から始めてください。 + + + +## ソースを準備する + +ビルドに必要な Hugo の設定、content、layouts、assets、およびすべてのテーマファイルを含めてください。Hugo の検出は、`hugo.toml`、`hugo.yaml`、`config/_default/` のような設定に加え、`content/` ディレクトリを探します。 + +| 設定 | 値 | +|---|---| +| ビルド | `hugo --minify` | +| Output | `public/` | +| Production server | nginx | +| サービスポート | `80` | + +`baseURL` には、末尾のスラッシュを含む想定公開サイト URL を設定します。別のホスト名を割り当てた後は再ビルドし、リンクや生成されるサイトマップ項目がそれを使うようにしてください。[Hugo の build and output guide](https://gohugo.io/getting-started/usage/) を確認してください。 + + + +## ビルド依存関係を確認する + +デフォルトの Hugo ビルドイメージは `hugomods/hugo:base` です。これはプロジェクト用の Hugo バージョンを固定しません。テーマに特定の Hugo バージョン、extended edition、または Node ツールが必要な場合は、それらの依存関係とテスト済みバージョンを含む完全な Dockerfile を使ってください。 + +Hugo の設定と `content/` により、Go や Node の検出より前に Hugo ビルダーが選択されます。`go.mod` を使う Hugo Modules プロジェクトでは、Go サポート付きのビルドイメージが使われます。`package.json` があると、ビルドは Dockerfile を要求して停止します。Node の依存関係をインストールし、assets をビルドしてから、`hugo --minify` を実行してください。[ビルドの決定順序](/concepts/build-pipeline#build-decision-order) を参照してください。 + + + +## ローカルでビルドしてデプロイする + +```bash +hugo --minify +hugo server +``` + +最初のコマンドの後で `public/` を確認してください。ローカルサーバーを使って content とテーマのレンダリングを確認してください。`hugo server` は本番の起動コマンドではありません。 + +[CLI setup](/framework-guides#prepare-the-project) の後、ソースディレクトリをデプロイします: + +```bash +lizard init --name hugo-site +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +生成されたホスト名を使う場合は、最初のデプロイ後にそれを確認してください: + +```bash +lizard service show web --json +``` + +そのホスト名を使って、`hugo.toml` の `baseURL` を設定します: + +```toml +baseURL = "https://YOUR_PUBLIC_HOST/" +``` + +ビルドで公開 URL が使われるように、変更した設定をアップロードします: + +```bash +lizard up --service web --port 80 +``` + + +ローカルの生成済み出力とシークレットは除外してください。アップロード時は、送信するディレクトリ内にテーマのソースファイルが実際に存在することを確認してください。リモートの submodule 参照だけではテーマ内容にはなりません。 + + + +## デプロイ済みサイトを確認する + +公開中のホームページ、内部記事、画像を開いてください。生成された canonical URL と `sitemap.xml` を確認します。適当な存在しないパスの HTTP ステータスもテストしてください。新しい Hugo ビルドは生成された HTML を配信し、存在しないページには HTTP 404 を返します。このガイドのシンプルなソース構成では、カスタム Dockerfile は不要です。現在のルーティングルールを反映するには、古いイメージを再ビルドしてください。 + +カスタム nginx ポリシーが必要な場合は、[静的ルートと404エラー](/framework-guides/static-routing) を使ってください。カスタム Hugo ビルドステージには、テーマが必要とする Hugo バージョンとツールを含め、`hugo --minify` を実行し、`public/` を配信用イメージにコピーする必要があります。 + +テーマ assets が見つからない場合は、ビルドログ、テーマソース、`baseURL` を確認してください。誤ったビルダーが起動する場合は、Hugo の設定と `content/` がアップロードのルートにあることを確認し、既存のサービスオーバーライドを調べてください。Hugo は静的ファイルを生成するため、content の変更には新しいビルドが必要です。 + +September 9, 2026 のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 + diff --git a/_locales/ja/framework-guides/index.mdx b/_locales/ja/framework-guides/index.mdx new file mode 100644 index 0000000..7ac2b33 --- /dev/null +++ b/_locales/ja/framework-guides/index.mdx @@ -0,0 +1,69 @@ +--- +description: "Next.js、React、Vue、Astro、Nuxt、SvelteKit、FastAPI、Django、Docusaurus、VitePress、Hugo を Lizard にデプロイします。ビルドコマンド、アダプター、ポート、確認項目を確認できます。" +--- + + + +# フレームワークガイド + +ソースからフレームワークアプリを Lizard にデプロイします。以下でフレームワークとレンダリングモードを選択し、本番ビルドを準備してから、Lizard CLI でデプロイするか GitHub リポジトリを接続してください。サーバーアプリはプロセスを実行します。静的サイトは生成されたファイルを nginx 経由で配信します。 + + + +## フレームワークを選ぶ + +これらの設定は、リンク先のガイドにある標準的なプロジェクト構成を説明しています。コマンドは JavaScript プロジェクトでは npm を前提としています。カスタム出力パス、アダプター、ビルドのオーバーライドによって結果が変わる場合があります。 + +| フレームワーク | ビルド | ランタイムまたは出力 | サービスポート | +|---|---|---|---| +| [Next.js](/framework-guides/nextjs) | `npm run build` | start スクリプト経由の `next start` | `3000` | +| [Next.js静的エクスポート](/framework-guides/nextjs/static-export) | `npm run build` | Dockerfile 経由の `out/` | `80` | +| [React with Vite](/framework-guides/react) | `npm run build` | `dist/` | `80` | +| [Vue with Vite](/framework-guides/vue) | `npm run build` | `dist/` | `80` | +| [Astro](/framework-guides/astro) | `npm run build` | `dist/`、または standalone Node アダプター | `80` static; `3000` server | +| [Nuxt](/framework-guides/nuxt) | `npm run build` | `node .output/server/index.mjs` | `3000` | +| [SvelteKit](/framework-guides/sveltekit) | `npm run build` | adapter-node を使った `node build` | `3000` | +| [FastAPI](/framework-guides/fastapi) | Python 依存関係をインストール | `uvicorn main:app --host 0.0.0.0 --port 8000` | `8000` | +| [Django](/framework-guides/django) | Python 依存関係をインストール | 使用する WSGI モジュールで Gunicorn | `8000` | +| [Docusaurus](/framework-guides/docusaurus) | `npm run build` | `build/` | `80` | +| [VitePress](/framework-guides/vitepress) | `npm run docs:build` | このガイドの `docs/.vitepress/dist/` | `80` | +| [Hugo](/framework-guides/hugo) | `hugo --minify` | `public/` | `80` | + + + +## プロジェクトを準備する + +コマンドはアプリケーションディレクトリから実行します。ソースファイル、設定、package lockfile をコミットしてください。アップロードには `.env`、ローカル依存関係、ローカルのビルド出力を含めないでください。Node プロジェクトでは `.nvmrc` で Node のメジャーバージョンを選択できます。現在のデフォルトは `22` です。これは正確なパッチリリースではなく、メジャーバージョンを選択します。 + +Lizard CLI をインストールし、一度サインインします: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +各ガイドでは、新しいプロジェクトと `web` または `api` という名前のサービスを使用します。最初の `lizard up --service` 呼び出しの前に、`lizard add --service web`（または `api`）でそのサービスを作成してください。`up --service` は既存のサービスを選択します。存在しない名前付きサービスは作成しません。既存のプロジェクトでは、デプロイ前に `lizard status --json` と `lizard ps --json` を確認してください。ポートはコンテナ内のプロセスと一致している必要があり、そのプロセスは `0.0.0.0` で待ち受ける必要があります。 + +Lizard CLI 0.3.95 は、アップロード時に macOS のアーカイブメタデータを除外します。`COPYFILE_DISABLE` の設定は不要です。これらのガイドに従う前に、古い CLI バージョンを更新してください。 + + + +## GitHub またはローカルソースを選ぶ + +ガイドのコマンドでは、現在のフォルダーをアップロードするために `lizard up` を使います。このコマンドは、既存のサービスをソースアップロードに変更します。git push to deploy を維持したい場合は、代わりに [GitHub を接続](/deploy/github) し、リポジトリでガイドのビルド設定を使用してください。テーブルの内容に従ってサービスのポートを設定します。 + + + +## ビルド設定の整合性を保つ + +これらのガイドでは、Dockerfile が必要な場合を除き、lizardpack の検出を使います。既存の `buildCommand` または `startCommand` のオーバーライドは、検出とリポジトリの Dockerfile より優先されます。ビルド方法を切り替える前に、[ビルド決定順序](/concepts/build-pipeline#build-decision-order) を確認してください。ガイドで指示された場合は `package.json` にスクリプトを設定してください。CLI オーバーライドを追加するのは別のビルドパスです。 + + + +## リリースを確認する + +ビルドログ、ランタイムログ、アクティブな URL を確認します。内部ルート、不足しているルート、API やフォームアクションがあればそれもテストしてください。ポートを開くプロセスでも、壊れたページを返すことがあります。生成サイトでは、未知の URL すべてに対して HTTP 200 でホームページを返さないよう、[静的ルートと 404](/framework-guides/static-routing) を使用してください。 + +ランタイムのサポートは、共有キャッシュ、永続的なローカルファイル、またはすべてのフレームワークバージョンを意味するものではありません。アプリがそれらの機能に依存している場合は、[制限](/platform/limits)、[ストレージと復旧](/platform/storage-and-recovery)、[既知の問題](/platform/known-issues) を確認してください。 + +September 9, 2026 のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/nextjs/_meta.ts b/_locales/ja/framework-guides/nextjs/_meta.ts new file mode 100644 index 0000000..91854ef --- /dev/null +++ b/_locales/ja/framework-guides/nextjs/_meta.ts @@ -0,0 +1,4 @@ +export default { + index: "Next.js", + 'static-export': { title: "静的エクスポート", display: "hidden" }, +}; diff --git a/_locales/ja/framework-guides/nextjs/index.mdx b/_locales/ja/framework-guides/nextjs/index.mdx new file mode 100644 index 0000000..da7f66a --- /dev/null +++ b/_locales/ja/framework-guides/nextjs/index.mdx @@ -0,0 +1,95 @@ +--- +description: "Next.js を Node.js サーバーとして Lizard にデプロイします。next build、next start、port 3000、環境変数、およびページ、API、Server Actions のチェックを設定します。" +--- + + + +# Next.js を Lizard にデプロイする + +`next build` と `next start` を使って、Next.js を Node.js サーバーとして Lizard で実行します。この方法では、リクエスト時レンダリング、Route Handlers、Server Actions のためにサーバーを利用可能な状態に保てます。すべてのルートを事前にビルドできる場合は、代わりに [Next.js静的エクスポート](/framework-guides/nextjs/static-export) に従ってください。 + + + +## ビルド設定 + +| 設定 | 値 | +|---|---| +| プロジェクト root | `package.json` と Next.js 設定を含むディレクトリ | +| ビルド script | `next build` | +| Start script | `next start --hostname 0.0.0.0 --port 3000` | +| ビルド output | `.next/` | +| サービスポート | `3000` | +| ランタイム | Node.js | + + + +## アプリを準備する + +`next`、`react`、`react-dom` を依存関係に含めたままにし、lockfile をコミットしてください。これらのスクリプトを `package.json` に統合します: + +```json +{ + "scripts": { + "dev": "next dev", + "build": "next build", + "start": "next start --hostname 0.0.0.0 --port 3000" + } +} +``` + +このガイドでは標準の Next.js 出力を使用します。`output: 'export'` には静的サーバーが必要で、`output: 'standalone'` には独自の `server.js` 起動とアセット配置が必要です。どちらもこの `next start` の手順をそのままでは使用しません。 + +`.nvmrc` で、`22` などのサポート対象の Node メジャーバージョンを選択します。アップロードするソースから `.next/`、`node_modules/`、`.env*` を除外してください。必要であれば、シークレットを含まないサンプル環境ファイルは残します。 + + + +## 本番ビルドをローカルでテストする + +```bash +npm ci +npm run build +npm run start +``` + +別のターミナルで `http://localhost:3000` を開き、内部ルートをテストします。アプリに API または Server アクション がある場合は、それも実行して確認してください。開発サーバーのチェックだけを通過しても、本番ビルドが動作する証明にはなりません。 + + + +## デプロイ + +[Lizard CLIのインストールとサインイン](/framework-guides#prepare-the-project) の後、アプリのディレクトリから次を実行します: + +```bash +lizard init --name nextjs-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Lizard は `next` の依存関係を検出し、ビルドスクリプトと起動スクリプトを実行します。これらのコマンドは、サービスに既存のビルドまたは起動のオーバーライドがないことを前提としています。ローカルでのチェックを繰り返すには、デプロイ出力内の URL を使用してください。 + + + +## 環境変数とデータ + +`NEXT_PUBLIC_*` の値は、ビルド中にブラウザバンドルの一部になります。認証情報はサーバー専用の変数に保持し、サービスに対して [変数とシークレット](/variables) から設定してください。ビルド中にデータを取得するコードは、ビルド時にもそのデータへアクセスできる必要があります。ランタイムを再起動しても、すでに生成済みの HTML や JavaScript は変更されません。 + +ローカルキャッシュファイルとアップロードされたファイルは、レプリカ間で共有されるストアにはなりません。1 レプリカを超えてスケールする前に、Next.js のキャッシュ要件と Server アクション の要件を確認してください。永続的なアプリデータはデータベースまたはオブジェクトストレージに保存し、[ストレージとリカバリ](/platform/storage-and-recovery) を読んでください。 + + + +## トラブルシューティング + +| 症状 | 確認 | +|---|---| +| `Missing script: start` | 上記の本番用起動スクリプトを追加してください。`next dev` はローカル開発用です。 | +| アプリが正常状態にならない | `--port 3000` を起動コマンドに一致させ、`0.0.0.0` にバインドしてください。 | +| Public API URL がまだ古い値のまま | 新しい `NEXT_PUBLIC_*` の値で再ビルドしてください。 | +| ビルドがデータベースに到達できない | ルートがビルド時にデータを取得しているか、その依存先がその時点で到達可能かを確認してください。 | +| `next start` で static export が失敗する | 別の static export ガイドに従ってください。 | + +[Next.jsセルフホスティングガイド](https://nextjs.org/docs/app/guides/self-hosting) では、フレームワークレベルのキャッシュ、画像、マルチインスタンス動作を扱っています。デプロイエラーについては、[サービスが常にhealthyにならない](/deploy/troubleshooting/service-never-healthy) を参照してください。 + +September 9, 2026 のデプロイチェックとその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/nextjs/static-export.mdx b/_locales/ja/framework-guides/nextjs/static-export.mdx new file mode 100644 index 0000000..ebc8a3d --- /dev/null +++ b/_locales/ja/framework-guides/nextjs/static-export.mdx @@ -0,0 +1,106 @@ +--- +description: "output export、nginx Dockerfile、ポート 80、実際の 404 レスポンスを使って、Lizard に Next.js の static export をデプロイします。引き続き Node.js サーバーが必要な機能も確認できます。" +--- + + + +# Next.js の static export をデプロイする + +Next.js の static export は、HTML、JavaScript、アセットを `out/` に生成します。nginx Dockerfile を使って、そのディレクトリを Lizard にデプロイします。事前にビルドできるページではこの方法を使い、リクエスト時のサーバー機能については [Node.js server ガイド](/framework-guides/nextjs) を使ってください。 + + + +## export を設定する + +これらのオプションを `next.config.mjs` にマージします: + +```js +/** @type {import('next').NextConfig} */ +const nextConfig = { + output: 'export', + trailingSlash: true, + images: { unoptimized: true }, +}; + +export default nextConfig; +``` + +`"build": "next build"` は `package.json` のままにしてください。この例では通常の export された画像を使います。外部の画像ローダーも別の選択肢です。必要な動的ルートパラメーターはすべてビルド中に生成してください。リクエスト時の cookies、Server Actions、および実行中の Next.js サーバーを必要とするその他の機能は、この static コンテナでは実行できません。アプリで使っている機能については、[Next.js静的エクスポート リファレンス](https://nextjs.org/docs/app/guides/static-exports) を確認してください。 + + + +## 完全な Dockerfile を追加する + +Next.js の自動検出パスは Node サーバーを前提としています。設定で `out/` を export していても、自動的に nginx へ切り替わることはありません。この Dockerfile をアプリのルートに追加してください。npm と、コミット済みの `package-lock.json` を前提としています: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +RUN npm run build + +FROM nginx:alpine +COPY --from=build /app/out /usr/share/nginx/html +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +その横に `nginx.conf` を作成します: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + location / { + try_files $uri $uri/ =404; + } + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +末尾スラッシュ付きの export では、`index.html` を持つルートディレクトリが作成されます。nginx ルールはそれらのディレクトリを配信し、存在しないパスには HTTP 404 を返します。`node_modules`、`.next`、`out`、`.git`、`.env*` を `.dockerignore` に追加し、ローカルのビルドファイルがアップロードに含まれないようにしてください。 + + + +## ビルドしてデプロイする + +```bash +npm ci +npm run build +``` + +`out/index.html` と、想定どおりの内部ルートが存在することを確認してください。Docker が利用できる場合は、実際のサーバーをローカルでテストします: + +```bash +docker build -t nextjs-static . +docker run --rm -p 8080:80 nextjs-static +``` + +[CLI セットアップ](/framework-guides#prepare-the-project) の後、新しいサービスにデプロイします: + +```bash +lizard init --name nextjs-static +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +完全な Dockerfile には、lizardpack が認識できる npm build ステップが含まれています。既存のサービスでは、Dockerfile を選択する前に、競合する build/start オーバーライドを確認してクリアしてください。詳細は [ビルドの決定順序](/concepts/build-pipeline#build-decision-order) を参照してください。 + + + +## ルートと更新を確認する + +公開中のホームページ、export された内部ルート、JavaScript アセット、そして存在しない適当なパスをリクエストしてください。存在しないパスは、HTTP 200 のホームページではなく、HTTP 404 を返す必要があります。[静的ルートと404エラー](/framework-guides/static-routing#verify-http-responses) の確認手順を使ってください。 + +export されたコンテンツの変更はすべて、新しいビルドが必要です。ランタイム環境変数では、`out/` にすでに書き込まれた値は変更できません。カスタム Dockerfile で公開用の build 変数を使う場合は、必要な `ARG` を `RUN npm run build` の前に宣言してください。秘密の認証情報を export 済みバンドルに入れないでください。 + +2026年9月9日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/nuxt.mdx b/_locales/ja/framework-guides/nuxt.mdx new file mode 100644 index 0000000..64e2ef2 --- /dev/null +++ b/_locales/ja/framework-guides/nuxt.mdx @@ -0,0 +1,109 @@ +--- +description: "Nitro の node-server プリセットで Nuxt を Lizard にデプロイします。本番用 start スクリプトを追加し、生成されたサーバーをポート 3000 で実行して、ルートと runtime config を確認します。" +--- + + + +# Nuxt を Lizard にデプロイする + +Nitro の `node-server` プリセットで Nuxt を Lizard 上で実行します。ビルドでは `.output/server/index.mjs` が生成され、Node.js プロセスがポート `3000` でページとサーバールートを配信します。ポート `80` の生成サイトについては、以下の静的レシピを使用してください。 + + + +## 本番ビルドを設定する + +[プロジェクトの準備](/framework-guides#prepare-the-project) の最新の Lizard CLI を使用してください。Version 0.3.95 では、アップロード時に macOS のアーカイブメタデータが除外されます。古い CLI が `._*.ts` のルートエラーを報告する場合は、CLI を更新してから再度アップロードしてください。 + +`nuxt.config.ts` でプリセットを設定します: + +```ts +export default defineNuxtConfig({ + nitro: { preset: 'node-server' }, +}); +``` + +これらのスクリプトを `package.json` にマージし、アプリに必要な他のスクリプトはそのまま残してください: + +```json +{ + "scripts": { + "dev": "nuxt dev", + "build": "nuxt build", + "start": "HOST=0.0.0.0 PORT=3000 node .output/server/index.mjs" + } +} +``` + +start スクリプトは、デプロイコンテナ内の Linux シェルを使用します。lizardpack は `nuxt` 依存関係を検出し、build スクリプトと start スクリプトを実行します。新規の Nuxt プロジェクトには `start` が含まれていない場合があります。その場合は、`nuxt dev` が本番ビルドを配信すると想定せず、これを追加してください。 + +| 設定 | 値 | +|---|---| +| ビルド | `npm run build` | +| Server entry | `.output/server/index.mjs` | +| Start | `npm run start` | +| サービスポート | `3000` | + + + +## ビルドしたアプリをテストする + +```bash +npm ci +npm run build +npm run start +``` + +`http://localhost:3000` を開き、内部ページを直接リクエストし、存在する場合は `server/api` ルートのいずれかを呼び出してください。ビルドが Node server プリセットを報告していることを確認します。プロバイダー固有の Nitro プリセットでは、異なるエントリーポイントが生成されることがあります。 + + + +## デプロイ + +[CLI のセットアップ](/framework-guides#prepare-the-project) の後、Nuxt アプリのディレクトリで次を実行します: + +```bash +lizard init --name nuxt-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +`.nuxt/`、`.output/`、`node_modules/`、`.env` ファイルはアップロード対象から除外してください。ソース、設定、lockfile は含めてください。既存のサービスの build/start 上書き設定は、ここで使用される検出をバイパスします。[ビルドの決定順序](/concepts/build-pipeline#build-decision-order) を参照してください。 + + + +## ランタイム設定 + +runtime 設定は `runtimeConfig` で宣言し、サービスには対応する `NUXT_*` 値を設定してください。シークレットは `runtimeConfig.public` の外に置いてください。public 部分はブラウザに届きます。ページの prerender に使用される値は生成済みビルドにも影響するため、変更後はリクエスト時のルートと prerender 済みルートの両方を確認してください。 + +サービスの設定には [変数とシークレット](/variables) を、永続データには [ストレージとリカバリ](/platform/storage-and-recovery) を使用してください。ローカルキャッシュやセッションファイルを、レプリカ間で共有されるストレージとして扱わないでください。 + + + +## トラブルシューティング + +プロセスが `.output/server/index.mjs` の不足を報告する場合は、プリセットとビルド出力を確認してください。start スクリプトがないと報告される場合は、上記のものを追加してください。サイトがいつまでも healthy にならない場合は、host と port を確認してください。 + +完全に生成された Nuxt サイトでは、静的 Dockerfile と正しいルート処理で `.output/public/` を配信してください。その出力を上記の Node コマンドで起動しないでください。[Nuxtデプロイガイド](https://nuxt.com/docs/4.x/getting-started/deployment) では Node 出力と生成出力が説明されています。[静的ルートと404エラー](/framework-guides/static-routing) では Lizard の静的サーバー設定を扱っています。 + + + +## 静的サイトを生成する + +生成 HTML の場合は、Node プリセットを明示的な prerender 設定に置き換え、build スクリプトを `nuxt generate` に変更します: + +```ts +export default defineNuxtConfig({ + nitro: { + prerender: { crawlLinks: true, routes: ['/'] }, + }, +}); +``` + +クローラーが発見できない未リンクまたは動的ルートは、`routes` に追加してください。`npm run build` を実行し、`.output/public/index.html` と内部ルートファイルが存在することを確認してください。Nuxt 4.5.2 でのテストでは、`preset: 'node-server'` を残したまま `nuxt generate` のみに切り替えると、サイトのルートがないフォールバックページが生成されました。ビルドが成功しただけでは、エクスポートにサイトが含まれていることは確認できませんでした。 + +[静的ルートと404エラー](/framework-guides/static-routing) の Dockerfile と nginx 設定を使用し、build スクリプトは `build`、出力ディレクトリは `.output/public`、service port は `80` にしてください。静的コンテナは Nuxt server routes を実行せず、すでに生成済みのページについて runtime config も読み取りません。 + +2026年9月9日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/react.mdx b/_locales/ja/framework-guides/react.mdx new file mode 100644 index 0000000..0b7c6d8 --- /dev/null +++ b/_locales/ja/framework-guides/react.mdx @@ -0,0 +1,83 @@ +--- +description: "Lizard で Vite で構築した React アプリをデプロイします。dist をビルドし、port 80 で配信し、クライアントルートと公開 API 変数を設定して、デプロイしたアプリを確認します。" +--- + + + +# Lizard で React with Vite をデプロイ + +Lizard は Vite を使用する React アプリをビルドし、その `dist/` ディレクトリを nginx 経由で port `80` で配信します。このガイドはブラウザでレンダリングされるアプリを対象としています。サーバーが必要な React ページについては、[Next.js ガイド](/framework-guides/nextjs)に従うか、選択した React フレームワーク向けの本番サーバーを用意してください。 + + + +## ビルドを準備する + +コミット済みの lockfile がある既存の React と Vite のプロジェクトを使用します。その `package.json` には本番ビルドスクリプトが必要です: + +```json +{ + "scripts": { + "dev": "vite", + "build": "vite build", + "preview": "vite preview" + } +} +``` + +スキャフォールドが `vite build` の前に TypeScript チェックを実行する場合は、そのチェックを維持してください。Vite のデフォルトの `dist` 出力ディレクトリはそのまま使用してください。カスタムの `build.outDir` を使う場合は、標準の検出パスが `dist` をコピーするため、それに対応する Dockerfile が必要です。 + +| 設定 | 値 | +|---|---| +| Detection | dependencies または dev dependencies 内の `vite` | +| ビルド | `npm run build` | +| Output | `dist/` | +| Production server | nginx; Node の start スクリプトは不要 | +| サービスポート | `80` | + + + +## ローカルでテストする + +```bash +npm ci +npm run build +npm run preview +``` + +ローカルのプレビュー URL を開き、API を呼び出すページをテストします。preview コマンドはビルドをローカルで確認するためのものです。本番の start コマンドとして `vite preview` を設定しないでください。[Vite deployment](https://vite.dev/guide/static-deploy.html) を参照してください。 + + + +## ソースをデプロイする + +[CLI setup](/framework-guides#prepare-the-project) の後、`package.json` を含むディレクトリから実行します: + +```bash +lizard init --name react-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +ソースと lockfile をアップロードし、`node_modules/`、`dist/`、および secrets は除外します。静的検出パスを使うため、service build/start overrides は未設定のままにしてください。nginx コンテナは、development サーバーや preview サーバーが別の port を使っていても、port 80 で待ち受けます。 + + + +## API を接続する + +API のブラウザから到達可能な HTTPS アドレスには、`VITE_API_URL` のような公開変数を使用します。これを `import.meta.env.VITE_API_URL` として読み取ります。この値は [変数とシークレット](/variables) で設定し、変更時には再ビルドしてください。データベース URL、API credential、または internal-only service address を `VITE_*` 変数で公開してはいけません。 + +別オリジン上の API の場合は、許可する origin にフロントエンド URL を含めるよう設定してください。バックエンドサービス間で機能する private service hostname は、訪問者のブラウザでは解決されません。 + + + +## ルーティングを確認する + +公開中のアプリを開き、クライアントルートをたどってから、その URL を直接リロードします。デフォルトの静的サーバーは `index.html` にフォールバックするため、クライアントルーターが内部ルートをレンダリングできます。React アプリ側にも未知のパス用のルートを追加してください。このフォールバックは HTTP 200 を返します。実際の HTTP 404 レスポンスが必要なページでは、[静的ルートと404エラー](/framework-guides/static-routing) を使ってサーバーポリシーを選択してください。 + +asset が HTML を返す場合やページが真っ白になる場合は、Vite の `base`、要求された asset URL、および出力ディレクトリを確認してください。アプリがいつまでも healthy にならない場合は、service port が `80` であることと、古い start-command override によって別のビルドパスが選ばれていないことを確認してください。 + +検索に表示させたいページについては、最初の HTML レスポンスを確認してください。ブラウザレンダリングの shell には、検索エンジンや answer engine に読ませたいテキストが含まれていない場合があります。レスポンス内にそのテキストが必要な場合は、prerendering またはサーバーフレームワークを選択してください。 + +2026 年 9 月 9 日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 diff --git a/_locales/ja/framework-guides/static-routing.mdx b/_locales/ja/framework-guides/static-routing.mdx new file mode 100644 index 0000000..14ad077 --- /dev/null +++ b/_locales/ja/framework-guides/static-routing.mdx @@ -0,0 +1,107 @@ +--- +description: "Lizard で静的サイトのルートを設定します: 生成された HTML を配信し、クリーン URL をサポートし、存在しないページには HTTP 404 を返し、SPA フォールバックが適切な場面を選びます。" +--- + + + +# 静的ルートと 404 + +生成コンテンツのサイトでは、各ルートの HTML を配信し、存在しないページには HTTP 404 を返すべきです。Astro static、Docusaurus、VitePress、Hugo、SvelteKit adapter-static 向けの新しい lizardpack ビルドでは、そのポリシーを使用します。React と Vue の SPA では、ブラウザルーターに必要な `index.html` フォールバックを維持します。 + +以下のカスタム設定は任意です。検出されたフレームワークで提供されないルーティングポリシーに使ってください。既存のイメージは、再ビルドするまで以前のルールを維持します。 + + + +## ルーティングポリシーを選ぶ + +| アプリ タイプ | ルート動作 | +|---|---| +| React または Vue SPA | 有効なクライアントルートでは `index.html` が読み込まれ、その後クライアントルーターがそれをレンダリングします。 | +| 生成されたドキュメントまたはコンテンツ | ルートは生成された HTML に解決されます。未知のパスは HTTP 404 を返します。 | +| サーバーレンダリングアプリ | アプリケーションサーバーがルートを解決し、ステータスを返します。 | + +SPA の catch-all view では存在しないページのメッセージを表示できますが、ブラウザコードはすでに送信済みの HTML レスポンスの HTTP ステータスを変更できません。SPA でルート認識の HTTP ステータスが必要な場合は、どのパスが存在するかを把握しているサーバーまたは事前レンダリングされたルート構成を使用してください。 + + + +## 生成ページ向けに nginx を設定する + +アプリケーションルートに `nginx.conf` を作成します: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + + location / { + try_files $uri $uri.html $uri/ =404; + } + + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +これは `guide.html` と `guide/index.html` の両方の出力レイアウトをサポートします。カスタムエラーページを使いたい場合は、生成された `404.html` を含めてください。それ以外の場合は、nginx のデフォルトのエラーボディを使うために `error_page` と exact-location ブロックを省略してください。サイトのリンクとサイトマップでは、正規 URL スタイルを 1 つに統一してください。このルックアップルールは正規リダイレクトを追加しません。 + + + +## この設定でサイトをビルドする + +コミット済み lockfile がある npm プロジェクトでは、この完全な Dockerfile を使用してください。以下の表に合わせて、`BUILD_SCRIPT` と `OUTPUT_DIR` のデフォルト値を変更します: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +ARG BUILD_SCRIPT=build +RUN npm run "$BUILD_SCRIPT" + +FROM nginx:alpine +ARG OUTPUT_DIR=dist +COPY --from=build /app/${OUTPUT_DIR}/ /usr/share/nginx/html/ +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +| サイト | `BUILD_SCRIPT` | `OUTPUT_DIR` | +|---|---|---| +| Astro static | `build` | `dist` | +| Docusaurus | `build` | `build` | +| `docs/` ルートを持つ VitePress | `docs:build` | `docs/.vitepress/dist` | +| プロジェクトルートにある VitePress | `docs:build` または実際のスクリプト | `.vitepress/dist` | +| adapter-static を使う SvelteKit | `build` | `build` | +| Next.js export | `build` | `out` | +| Nuxt generate | `nuxt generate` を使う `build` | `.output/public` | + +生成ページのポリシーは、アプリにそれらのルートファイルがある場合にのみ使用してください。たとえば、SvelteKit の SPA フォールバックには、その専用のルーティングポリシーが必要です。[Next.js静的エクスポート](/framework-guides/nextjs/static-export) には、trailing-slash レイアウトを含む完全な手順があります。 + +依存関係、ビルド出力、`.git`、`.env*` は `.dockerignore` で除外してください。ビルドに公開変数が必要な場合は、ビルドコマンドの前にその `ARG` 値を宣言してください。秘密のシークレットをイメージやブラウザ出力にコピーしないでください。 + +[CLI setup](/framework-guides#prepare-the-project) の後、`lizard add --service web` でサービスを作成し、次に `lizard up --service web --port 80` でこのソースをデプロイします。サービスがすでに存在する場合は、add ステップをスキップしてください。既存のサービスでは、[ビルドの決定順序](/concepts/build-pipeline#build-decision-order) を確認してください。コマンドのオーバーライドが Dockerfile より優先される場合があります。設定ファイルだけでは生成済みの nginx 設定は置き換えられません。Dockerfile でそれをイメージにコピーする必要があります。 + + + +## HTTP レスポンスを確認する + +`SITE_URL` を実際のローカルテスト URL またはデプロイ済みオリジンに設定し、次に `/guide/` を存在するページに置き換えます: + +```bash +SITE_URL=https://YOUR_PUBLIC_HOST +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/guide/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/this-page-does-not-exist" +``` + +実在するページでは 200、存在しないパスでは 404 を期待してください。有効なルートが正規形式にリダイレクトされる場合は、リダイレクトを確認してから宛先を検証してください。実際のアセットと架空の `.js` パスもテストしてください。存在しないスクリプトで、ホームページが HTML としてステータス 200 で返ってはいけません。 + +最後に、ブラウザで内側のルートを直接開いて再読み込みします。クライアントナビゲーションが正しくても、サーバーのルーティングエラーが隠れることがあります。インデックスされるサイトを公開する前に、HTTP ステータスとあわせてフレームワークの正規 URL とサイトマップ設定を確認してください。 + +2026 年 9 月 9 日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 + diff --git a/_locales/ja/framework-guides/sveltekit.mdx b/_locales/ja/framework-guides/sveltekit.mdx new file mode 100644 index 0000000..26b10d8 --- /dev/null +++ b/_locales/ja/framework-guides/sveltekit.mdx @@ -0,0 +1,110 @@ +--- +description: "adapter-node を使って Lizard で SvelteKit をデプロイします。本番ビルド、port 3000、ORIGIN、form actions、および別個の adapter-static の経路を設定します。" +--- + + + +# Lizard で SvelteKit をデプロイする + +Lizard 向けの SvelteKit サーバーをビルドするには、`@sveltejs/adapter-node` を使用します。これにより `build/` が生成され、port `3000` で `node build` によって起動されます。adapter は明示的にインストールして設定してください。`adapter-auto` をまだ使用している scaffold では、Node のデプロイ先は確立されません。 + +まずは、このレシピで使用する設定とファイルを含む[完全なソース例](https://github.com/lizard-build/docs/tree/main/_examples/sveltekit)から始めてください。 + + + +## adapter を設定する + +```bash +npm install --save-dev @sveltejs/adapter-node +``` + +`svelte.config.js` では、既存の preprocess やその他の設定はそのままにしつつ、`kit.adapter` を Node adapter に設定します。 + +```js +import adapter from '@sveltejs/adapter-node'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +使用する予定のデプロイ adapter だけを残してください。特に、未使用の `@sveltejs/adapter-static` 依存関係があると、設定で adapter-node を import していても、現在の detector では static の経路が選ばれることがあります。 + +| 設定 | 値 | +|---|---| +| ビルド | `npm run build`、通常は `vite build` | +| Output | `build/` | +| ランタイム | `node build` | +| Host and port | `HOST=0.0.0.0`、`PORT=3000` | +| サービスポート | `3000` | + + + +## 本番サーバーをテストする + +```bash +npm ci +npm run build +HOST=0.0.0.0 PORT=3000 ORIGIN=http://localhost:3000 node build +``` + +サーバーレンダリングされたページを開き、アプリに form action がある場合は送信してください。このガイドで使用する検出では、adapter のデフォルト出力パスをそのまま維持してください。 + + + +## デプロイして公開 origin を設定する + +[CLI setup](/framework-guides#prepare-the-project) の後: + +```bash +lizard init --name sveltekit-app +lizard add --service web +lizard up --service web --port 3000 +lizard ps --json +``` + +`ORIGIN` には、デプロイ出力にある正確な公開 HTTPS origin を、パスなしで設定します。たとえば、このプレースホルダーを実際の URL に置き換えます。 + +```bash +lizard secrets set ORIGIN=https://YOUR_PUBLIC_HOST --service web +``` + +訪問者が使用する origin がカスタムドメインであれば、代わりにそちらを使用してください。変数変更後に forms を再確認してください。複数の許可された origins や proxy 由来の URL を使う場合は、[SvelteKit Nodeサーバーガイド](https://svelte.dev/docs/kit/adapter-node) を読み、信頼する proxy headers を意図的に設定してください。 + + + +## 検証とトラブルシュート + +`lizard logs --build --service web --json` と `lizard logs --service web --json` で build と runtime のログを確認します。内部ルートを直接開き、form を送信し、存在しないルートをリクエストしてください。 + +forms で cross-site submission error が報告される場合は、セキュリティチェックを無効にする前に `ORIGIN` を確認してください。`node build` がサーバーを見つけられない場合は、有効な adapter と出力パスを確認してください。lizardpack の経路を使うには、service command overrides は未設定のままにしてください。 + + + +## Static SvelteKit サイト + +必要なすべてのページを prerender できるアプリでは、`@sveltejs/adapter-static`、そのデフォルトの `build/` 出力、および service port `80` を使用できます。その出力では server actions や request-time endpoints は実行できません。必要な routes に対して prerendering を設定してください。パッケージをインストールするだけでは不十分です。 + +`@sveltejs/adapter-static` をインストールし、`svelte.config.js` の adapter import を置き換えます。 + +```js +import adapter from '@sveltejs/adapter-static'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +すべての routes を生成できるサイトでは、これを `src/routes/+layout.js` に追加します。 + +```js +export const prerender = true; +export const trailingSlash = 'always'; +``` + +未使用のデプロイ adapter は dependencies から削除してください。`npm run build` を実行し、`build/` に必要な各ページが含まれていることを確認します。デフォルト出力では、service command overrides は未設定のままにし、port `80` で新しい service をデプロイしてください。新しい build は生成された HTML を配信し、存在しないページには HTTP 404 を返します。nginx に server レシピの port `3000` を再利用しないでください。 + +生成された HTML routes と SPA fallback のどちらを選ぶかは、[静的ルートと404エラー](/framework-guides/static-routing) を参照してください。フレームワークのオプションと制限については、[SvelteKit静的アダプター](https://svelte.dev/docs/kit/adapter-static) を参照してください。 + +2026年9月9日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 + diff --git a/_locales/ja/framework-guides/validation.mdx b/_locales/ja/framework-guides/validation.mdx new file mode 100644 index 0000000..efb6057 --- /dev/null +++ b/_locales/ja/framework-guides/validation.mdx @@ -0,0 +1,72 @@ +--- +description: "2026年9月9日に行った 16 件の実際の Lizard CLI デプロイによるフレームワークガイド結果: テストしたバージョン、ルート、フォーム、マイグレーション、canonical URL、制限事項。" +--- + + + +# フレームワークガイドのテスト結果 + +2026年9月9日時点で、11 個のフレームワークにまたがる 16 件すべてのレシピが、Lizard CLI 0.3.95 でローカルビルドと新規クラウドデプロイに合格しました。公開されているセットアップに従い、各レシピごとに新しいプロジェクトとサービスを作成し、`lizard up` でソースをアップロードしました。これらの結果は、以下のバージョンと小規模テストアプリを対象としています。 + +クラウド実行では、ルート、API、フォームの 100 件のチェックに加え、リンクされた JavaScript と CSS ファイルの 45 件のチェックにも合格しました。Django のマイグレーション、データベースへの書き込みと読み取り、最終的な Docusaurus と Hugo サイトの URL も合格しました。 + + + +## テストしたレシピ + +| レシピ | テストしたバージョン | ポート | クラウドチェック | +|---|---|---|---| +| Next.js server | Next.js 16.3.4, React 19.2.8 | `3000` | 合格 | +| Next.js静的エクスポート | Next.js 16.3.4, React 19.2.8 | `80` | 合格 | +| React with Vite | React 19.2.8, Vite 8.2.2 | `80` | 合格 | +| Vue with Vite | Vue 3.5.42, Vue Router 5.3.1, Vite 8.2.2 | `80` | 合格 | +| Astro static | Astro 7.3.1 | `80` | 合格 | +| Astro Node サーバー | Astro 7.3.1, Node adapter 11.1.5 | `3000` | 合格 | +| Nuxt Node server | Nuxt 4.5.2 | `3000` | 合格 | +| Nuxt generate | Nuxt 4.5.2 | `80` | 合格 | +| SvelteKit Nodeサーバー | SvelteKit 2.70.3, Svelte 5.57.0, adapter-node 5.5.7 | `3000` | 合格 | +| SvelteKit static | SvelteKit 2.70.3, Svelte 5.57.0, adapter-static 3.0.10 | `80` | 合格 | +| Docusaurus | Docusaurus 3.10.2 | `80` | 合格 | +| VitePress、ドキュメントルート | VitePress 1.6.4 | `80` | 合格 | +| VitePress、プロジェクトルート | VitePress 1.6.4 | `80` | 合格 | +| FastAPI | FastAPI 0.141.1, Uvicorn 0.52.4 | `8000` | 合格 | +| Django | Django 6.1.1, Gunicorn 26.2.0, WhiteNoise 6.12.0, psycopg 3.3.5 | `8000` | 合格 | +| Hugo | Hugo 0.165.0 (extended) | `80` | 合格 | + +JavaScript ビルドでは Node 22 を使用し、Python ビルドでは Python 3.13 を使用しました。アップロードは macOS から `COPYFILE_DISABLE` なしで実行しました。パッケージマニフェストと lockfile は上記のバージョンを固定しています。コンテナイメージのタグは、パッケージ lockfile とは独立して変わる場合があります。 + + + +## 9月9日に確認した内容 + +- Linux コンテナ内でドキュメント記載のローカルビルドおよびサーバーコマンドを実行し、その後、各レシピに対して `lizard init`、`lizard add`、`lizard up` を実行しました。クラウドのビルドログとランタイムログを読み、最終的なサービスの状態とポートを確認しました。 +- 公開ホームページ、内部ルート、実在するアセット、存在しないページ、存在しない JavaScript パスをリクエストしました。静的コンテンツサイトは実際の 404 を返し、React と Vue はドキュメントどおり SPA フォールバックを維持しました。両方の VitePress レイアウトは clean URL で正しいコンテンツを返しました。 +- リクエスト時の API レスポンス、POST ハンドラー、SvelteKit フォーム結果、信頼されていないオリジンからのフォーム拒否を確認しました。デプロイされた Next.js Server アクション フォームを、その生成された action ID を使って HTTP 経由で送信し、リダイレクトと返された値を確認しました。 +- 生成されたホスト名を config に設定した後、Docusaurus と Hugo を再ビルドしました。Docusaurus の canonical URL と両方の sitemap は公開ホストを使用していました。 +- Managed Postgres に対して Django マイグレーションを 2 回実行し、テスト行の書き込みと読み取りを行い、収集済み静的ファイルを配信し、有効な CSRF フォームを受け入れ、トークンのないフォームを拒否しました。 + +各レシピでは、実行を分離するために異なる名前の個別テストプロジェクトを使用しました。workspace、region、JSON フラグにより、テストコンテキストを明示しました。build、start、および Dockerfile path のサービスオーバーライドは未設定のままにしました。ガイドに記載された Dockerfile を指定したのは、Next.js静的エクスポート、Nuxt generate、Django の各レシピのみです。Docusaurus、VitePress、Hugo、および SvelteKit Node のテストには、[公開されているソース例](https://github.com/lizard-build/docs/tree/main/_examples) が含まれていました。 + + + +## ブラウザチェック + +9月9日の実行では、ブラウザ内で React ボタンのクリックを確認しました。その後、ナビゲーションおよびページ読み取り中にブラウザ接続でタイムアウトが繰り返し発生したため、この実行は 16 件すべてのレシピについて新たなブラウザ合格を**主張しません**。HTTP ルートおよびフォームのチェックは独立して合格しました。 + +9月7日の実行には、ブラウザでのダイレクトルート再読み込み、React の操作、Vue Router ナビゲーション、Next.js Server Actions、SvelteKit フォーム送信が含まれていました。これらは引き続き、その以前の実行による結果です。 + + + +## 初回実行以降の修正 + +9月7日の実行では、サービス作成手順の欠落、Nuxt static preset の不一致、静的ルーティングの不具合、macOS のアーカイブメタデータ、failed-build の終了コード、ポート変更エラーが見つかりました。ガイドには現在、`lizard add` と修正済みの Nuxt static セットアップが含まれています。 + +9月8日の静的ルーティング再確認では、Astro static、SvelteKit static、Docusaurus、Hugo、および両方の VitePress レイアウトについて、カスタム Dockerfile なしで合格しました。新しいビルドにはそれらのルーティングルールが含まれています。既存のイメージでは再ビルドが必要です。 + +Lizard CLI 0.3.95 には、アーカイブおよび failed-build 終了コードの修正が含まれています。9月9日の本番チェックでは、サービスのポート変更と、アップロードおよび再ビルド中に明示的なポートが維持されることも検証しました。リリースノートと残っている制限事項については、[既知の問題](/platform/known-issues) を参照してください。 + + + +## これらの結果の制限事項 + +これらのチェックは、ソースアップロードとドキュメント記載のモードを対象としています。すべてのプラグイン、adapter、theme、framework バージョン、GitHub デプロイパス、データベース復旧手順、または複数レプリカのワークロードへの対応を確立するものではありません。Django の小規模テストアプリは、`check --deploy` によるセキュリティ警告を引き続き報告します。これは完全な本番セキュリティ設定ではありません。これらのテストは、検索順位や AI citations を測定するものではありません。リリース前に、アプリ固有のルートとデータ操作を確認してください。 diff --git a/_locales/ja/framework-guides/vitepress.mdx b/_locales/ja/framework-guides/vitepress.mdx new file mode 100644 index 0000000..b1153ba --- /dev/null +++ b/_locales/ja/framework-guides/vitepress.mdx @@ -0,0 +1,78 @@ +--- +description: "Lizard で VitePress を docs:build、正しい .vitepress/dist ディレクトリ、nginx、ポート 80 でデプロイします。クリーン URL を設定し、ドキュメントのルートと 404 を確認します。" +--- + + + +# Lizard で VitePress をデプロイする + +Lizard は VitePress のドキュメントサイトをビルドし、生成された HTML を nginx を通じてポート `80` で配信できます。npm スクリプトと出力ディレクトリを docs ルートに合わせてください: `vitepress build docs` は `docs/.vitepress/dist` を書き出し、`vitepress build` は `.vitepress/dist` を書き出します。 + +この手順で使用する設定とファイルを含む、[完全なソース例](https://github.com/lizard-build/docs/tree/main/_examples/vitepress) から始めてください。 + + + +## ビルドスクリプトを設定する + +`docs/` 内の Markdown ファイルでは、`package.json` に次のスクリプトを保持します: + +```json +{ + "scripts": { + "docs:dev": "vitepress dev docs", + "docs:build": "vitepress build docs", + "docs:preview": "vitepress preview docs" + } +} +``` + +| 設定 | このガイドでの値 | +|---|---| +| ビルド | `npm run docs:build` | +| Docs root | `docs/` | +| Output | `docs/.vitepress/dist/` | +| Production server | nginx | +| サービスポート | `80` | + +検出機能は `vitepress build` を含むスクリプトを見つけ、その root 引数を使用します。そのスクリプトは直接的で曖昧さのないものにしてください。シェルラッパー、複数の一致するスクリプト、またはカスタムの `outDir` では、明示的なビルド設定または Dockerfile が必要です。 + + + +## サイトをローカルで確認する + +```bash +npm ci +npm run docs:build +npm run docs:preview +``` + +内部の Markdown ページとアセットを確認してください。`cleanUrls: true` では、VitePress は拡張子のないルートへリンクします。本番サーバーは、それらの URL を生成された HTML ファイルに解決する必要があります。`base` は実際のパスプレフィックスに設定するか、ドメインルートの場合は `/` に設定してください。[VitePress deployment](https://vitepress.dev/guide/deploy) を参照してください。 + + + +## デプロイする + +[CLI setup](/framework-guides#prepare-the-project) の後、`docs/` の中からではなく、`package.json` を含むディレクトリから実行します: + +```bash +lizard init --name vitepress-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +VitePress の設定、Markdown、ソースアセット、package manifest、lockfile を含めてください。ローカル依存関係、生成済み出力、キャッシュ、シークレットは除外します。サービスの開始コマンドとして `vitepress dev` または `vitepress preview` は設定しないでください。 + + + +## クリーンルートと HTTP ステータスを確認する + +新しい VitePress ビルドは、拡張子のないルートを生成された `.html` ファイルに解決し、存在しない URL には HTTP 404 を返します。この検出経路を使うため、コマンドオーバーライドは未設定のままにしてください。標準出力にはカスタム Dockerfile は不要です。カスタムルーティングについては、[静的ルートと404エラー](/framework-guides/static-routing) を参照してください。 + +クリーン URL に直接アクセスして再読み込みしてください。存在しないパスをリクエストし、HTTP 404 を確認します。古いイメージが存在しないパスに対してホームページを返す場合は、現在のルーティングルールを反映するためにサービスを再ビルドしてください。 + +ビルドで `Missing script: build` と報告される場合は、選択したパスが VitePress detector を使用していること、およびサービスコマンドのオーバーライドがそれを置き換えていないことを確認してください。ビルドが成功しても nginx がドキュメントを配信しない場合は、スクリプトの docs root とコピーされた出力ディレクトリを比較してください。コンテンツまたは設定を変更した後は再ビルドしてください。 + +2026 年 9 月 9 日のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation) を参照してください。 + diff --git a/_locales/ja/framework-guides/vue.mdx b/_locales/ja/framework-guides/vue.mdx new file mode 100644 index 0000000..3d285c7 --- /dev/null +++ b/_locales/ja/framework-guides/vue.mdx @@ -0,0 +1,70 @@ +--- +description: "Lizard で Vite でビルドした Vue アプリをデプロイします。dist 出力、ポート 80、Vue Router の history モード、公開環境変数、本番チェックを設定します。" +--- + + + +# Lizard で Vite を使った Vue をデプロイする + +Vite でビルドした Vue アプリを、Lizard 上の静的 Web サービスとしてデプロイします。ビルドでは `dist/` が生成され、nginx がポート `80` でファイルを配信します。Nuxt のサーバーレンダリングとサーバールートについては、[Nuxt ガイド](/framework-guides/nuxt)を使用してください。 + + + +## プロジェクトを準備する + +Vue アプリのディレクトリで、`package.json`、lockfile、Vite 設定ファイルを使って実行します。TypeScript コードをチェックする場合は `vue-tsc` を含めて、scaffold の build スクリプトはそのまま維持してください。ビルドは、`dist/` に Vite バンドルを生成して完了する必要があります。 + +| 設定 | 値 | +|---|---| +| ビルド | `npm run build` | +| Output | `dist/` | +| Start command | 静的検出パスでは不要 | +| サービスポート | `80` | + +ドメインのルートでサイトを公開する場合は、`base: '/'` を維持してください。パスプレフィックスを使う場合は、Vite の base を router の base およびアプリが実際に動作する URL に合わせてください。出力ディレクトリをカスタマイズする場合は、そのディレクトリをコピーする Dockerfile が必要です。 + + + +## ローカルでビルドを確認する + +```bash +npm ci +npm run build +npm run preview +``` + +ローカルのプレビュー URL を使って、データを取得するコンポーネントと、router 経由で到達するページを確認してください。このローカル確認では `vite preview` を使用します。本番ファイルは nginx が配信します。ビルド出力とプレビュー動作については、[Vite のデプロイガイド](https://vite.dev/guide/static-deploy.html)を参照してください。 + + + +## デプロイ + +[CLI セットアップ](/framework-guides#prepare-the-project)の後、現在のソースディレクトリをデプロイします。 + +```bash +lizard init --name vue-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +アップロード対象から、ローカル依存関係、`dist/`、`.env` ファイルを除外してください。既存のコマンド上書きがない場合、lizardpack は Vite を検出して静的イメージをビルドします。サービスの起動コマンドとして `npm run dev` を追加しないでください。 + + + +## Vue Router history モード + +アプリで `createWebHistory` を使う場合、サーバーはクライアントルートへの直接リクエストを処理する必要があります。デフォルトの静的イメージはファイルを見つけられないときに `index.html` を配信するため、`/account` はハードリロード時でも Vue Router に到達できます。router base は Vite の base に合わせてください。たとえば `createWebHistory(import.meta.env.BASE_URL)` のように設定します。詳しくは [Vue Router の history モード](https://router.vuejs.org/guide/essentials/history-mode.html)を参照してください。 + +ホームページからのナビゲーションと、新しいタブで `/account` を開く操作の両方をテストしてください。存在しないクライアントルート向けに catch-all view を追加してください。サーバーのフォールバックは未知のパスでも HTTP 200 を返すため、検索向けの 404 レスポンスは提供しません。インデックスされるコンテンツサイトでこの構成を使う前に、[静的ルートと 404](/framework-guides/static-routing)を読んでください。 + + + +## 変数と API リクエスト + +Vite はビルド時に `VITE_*` の値をブラウザバンドルへ書き込みます。これらは、API の公開 HTTPS URL など、公開してよい値にのみ使用してください。[変数とシークレット](/variables)で設定し、その後、再ビルドされたアプリの実際のネットワークリクエストを確認してください。ランタイムのみの再起動では、ビルド済み JavaScript 内の値は置き換えられません。 + +デプロイ後にのみリクエストが失敗する場合は、API 側の CORS を確認し、ブラウザが `localhost` やプライベートなバックエンドホスト名を呼び出していないことを確認してください。HTML は読み込まれるのにアセットが失敗する場合は、Vite の base とアセットパスを確認してください。JavaScript 実行前に HTML が必要なページでは、Nuxt レンダリングまたは明示的な prerendering ステップを選択してください。 + +September 9, 2026 のデプロイ確認とその制限については、[テスト済みバージョンとクラウド結果](/framework-guides/validation)を参照してください。 diff --git a/_locales/ja/getting-started.mdx b/_locales/ja/getting-started.mdx new file mode 100644 index 0000000..c0f2bdc --- /dev/null +++ b/_locales/ja/getting-started.mdx @@ -0,0 +1,134 @@ +--- +description: "lizard CLI をインストールし、ログインして、GitHub リポジトリまたはローカルフォルダから数分で最初のアプリを公開し、その後データベースを追加します。" +--- + + + +# アプリ クイックスタート + +数分で最初のアプリを Lizard に公開できます。Node.js 18+ と npm が必要です。`lizard login` した最初のタイミングで、Lizard アカウントは自動的に作成されます。CLI をインストールしてログインし、デプロイします。方法は GitHub リポジトリから直接行うか、ローカルディレクトリから行うかのどちらかです。 + + + +## 1. CLI をインストールする + +npm から `lizard` バイナリをグローバルにインストールします: + +```bash +npm install -g @lizard-build/cli +``` + +`PATH` 上にあることを確認します: + +```bash +lizard --version +``` + +> **`npx` は使わないでください。** 必ずグローバルにインストールされた `lizard` バイナリを使ってください。`npx @lizard-build/cli` を実行すると、その場限りのコピーが取得され、バージョンがプラットフォームとずれる可能性があります。後で `lizard upgrade` を使ってその場でアップグレードしてください。 + +> **権限エラー (EACCES)?** `sudo` は使わないでください。代わりに npm の保存先をユーザー所有の prefix に向けてください: +> ```bash +> mkdir -p ~/.npm-global +> npm config set prefix ~/.npm-global +> echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc && source ~/.zshrc +> npm install -g @lizard-build/cli +> ``` + + + +## 2. ログインする + +```bash +lizard login +``` + +ブラウザが開いて認証し、確認するとターミナルに戻ります。CI やその他の非対話環境では、代わりにトークンで認証します: + +```bash +export LIZARD_TOKEN=lzd_xxx +# or +lizard login --token lzd_xxx +``` + +現在どのアカウントであるかはいつでも確認できます: + +```bash +lizard whoami +``` + + + +## 3. デプロイする + +コードがどこにあるかに応じて、該当する方法を選んでください。 + + + +### オプション A — GitHub リポジトリをデプロイする（推奨） + +コードが GitHub 上にある場合は、リポジトリから直接サービスを作成します。Lizard がそれをクローンし、スタックを自動検出してビルドし、公開 URL を返します: + +```bash +lizard add -r your-org/your-app +``` + +以後、その追跡ブランチへの push によって自動的に再デプロイされます。プライベートリポジトリの場合は、先に GitHub App を接続してください: + +```bash +lizard git connect +``` + + + +### オプション B — ローカルコードをデプロイする + +プロジェクトディレクトリ内から、現在のフォルダをアップロードしてデプロイします（`.gitignore` を尊重します）: + +```bash +lizard up +``` + +ディレクトリがまだプロジェクトにリンクされていない場合、`up` が対話的に作成または選択を行います。CI では、先に `lizard init --name my-project` で明示的にリンクしてください。 + +どちらの場合でも、ビルドが完了すると `https://your-app-production.onlizard.com` のような生成済み URL が取得できます。 + + + +## 4. ビルドと実行を確認する + +```bash +lizard ps # services in the project, with status + URL +lizard logs # last runtime log lines +lizard logs --build # the most recent build's logs +lizard open # open the project in the dashboard +``` + + + +## 5. データベースを追加する（任意） + +マネージド Postgres をプロビジョニングし、サービスから参照します: + +```bash +lizard add postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service your-app +lizard redeploy --service your-app +``` + +`${{postgres.DATABASE_URL}}` 参照はデプロイ時に解決され、addon とともに自動的にローテーションされます。[Managed Addons](/addons) を参照してください。 + + + +## 次のステップ + +- **[Core 概念](/concepts/architecture)** — プロジェクト、サービス、ビルドパイプラインを理解します。 +- **[GitHubからのデプロイ](/deploy/github)** — ブランチ、モノレポ、自動再デプロイ。 +- **[変数 & Secrets](/variables)** — スコープと優先順位。 +- **[Networking](/networking)** — 自動 TLS で独自のホスト名を接続します。 +- **[AI IDEが構築したアプリをデプロイする](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production)** — Google Antigravity で書かれたアプリについて、同じ 3 つの手順を代わりにエージェントに渡します。 + + + +## ホスティング費用 + +Lizard は月額サブスクリプションなしの [pay as you go](/platform/billing) を採用しています。リソース使用量はアカウント残高から差し引かれます。購入したクレジットに有効期限はありません。トライアルクレジットには有効期限があります。デプロイ前に [pricing](https://lizard.build/pricing) とアカウントの上限を確認してください。 diff --git a/_locales/ja/guides/_meta.ts b/_locales/ja/guides/_meta.ts new file mode 100644 index 0000000..e5f1988 --- /dev/null +++ b/_locales/ja/guides/_meta.ts @@ -0,0 +1,2 @@ +export default { index: "ガイドを選ぶ", 'deploy-from-coding-agent': "コーディングエージェントからデプロイ", 'deploy-mcp-server': "リモートMCPサーバーをホスト", 'telegram-bot': "Telegramボットを実行", umami: "Umamiを実行", flowise: "PostgreSQLでFlowiseを実行", validation: "テスト結果" }; + diff --git a/_locales/ja/guides/deploy-from-coding-agent.mdx b/_locales/ja/guides/deploy-from-coding-agent.mdx new file mode 100644 index 0000000..7cad3eb --- /dev/null +++ b/_locales/ja/guides/deploy-from-coding-agent.mdx @@ -0,0 +1,139 @@ +--- +description: "Lizard Skill と Lizard CLI を使って、Claude Code、Codex、または Cursor からアプリをデプロイします。GitHub またはローカルソースを選択し、データベースを接続して、結果を確認します。" +--- + + + +# コーディングエージェントからデプロイする + +コーディングエージェントは、Lizard Skill と Lizard CLI を使って、自身が構築したアプリをデプロイできます。エージェントはインストール済み CLI のガイドを読み、対象プロジェクトを確認し、ビルドを実行して、結果を確認します。これに別途のMCPトランスポートは不要です。 + + + +## 始める前に + +動作するアプリケーション、そのデプロイ権限、および Lizard のアカウントを用意してください。アプリケーションは `0.0.0.0` と設定されたポートで待ち受ける必要があります。クラウドビルドを始める前に、ローカルチェックを実行してください。 + + + +## 現在のガイドをエージェントに渡す + +```bash +npm install -g @lizard-build/cli +lizard skills get core --json +lizard --help --json +``` + +Lizard Skill は、インストール済み CLI に一致する手順を読み込みます。特定のコマンドについては、フラグを推測せず、そのスキーマを読んでください: + +```bash +lizard up --help --json +lizard service set --help --json +``` + +便利なプロンプトの例: + +> このアプリを Lizard でデプロイしてください。インストール済み CLI のガイドを読み、リンクされたプロジェクトとサービスを確認し、アプリのチェックを実行して、ビルド結果と動作する URL を示してください。既存の本番サービスを変更したりデータを削除したりする前には確認してください。 + + + +## ローカルソースをデプロイする + +完全なテストには、[agent-appの例](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/agent-app) を使ってください。これは Node.js 22 と `pg` 8.16.3 を使用し、port 3000 で待ち受け、Managed Postgres から 1 行読み取ります。起動時に、存在しない場合はデモ用のテーブルと行を作成します。より大きなアプリケーションでは、独自のマイグレーションプロセスを使用してください。 + +例を専用ディレクトリにコピーし、ローカルチェックを実行します: + +```bash +npm ci +npm run check +lizard status --json +``` + +これは JavaScript の構文をチェックします。データベースと公開 HTTP のチェックはデプロイ後に行います。このディレクトリがすでにリンクされている場合は、それが意図したプロジェクトであることを確認してください。新しいテストプロジェクトの場合: + +```bash +lizard init --name agent-example --json +lizard add --service api --json +lizard add postgres --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api --json +lizard up --service api --port 3000 --json +``` + +データベースの実際の名前が `postgres` でない場合は、その名前を使用してください。ローカルシェルで展開されないよう、参照は引用符で囲んだままにしてください。最初のデプロイ前に設定してください。コマンドが認証必須と報告した場合にのみ、`lizard login` でサインインしてください。 + +このコピーした例では、アップロードパスは意図的なものです。すでに GitHub にあるアプリケーションの場合は、代わりに次のセクションを使用してください。macOS で Lizard CLI 0.3.92 を使う場合は、AppleDouble メタデータを除外するために `COPYFILE_DISABLE=1 lizard up --service api --port 3000 --json` を実行してください。その CLI バージョンでは、ビルドが失敗しても code 0 で終了することがあります: ターミナルの `failed`/`deployed` event を確認し、アプリケーションを検証してください。[既知の問題](/platform/known-issues) を参照してください。 + + + +## GitHub からデプロイする + +アプリケーションに GitHub リポジトリがある場合は、この方法を使用します。まず remote を確認してください: + +```bash +git remote get-url origin +lizard status --json +lizard ps --json +``` + +リンク済みのテストプロジェクトを使うか、`lizard init --name YOUR_PROJECT_NAME` で作成してください。ビルドを開始せずにリポジトリを接続し、環境を設定する時間を確保します: + +```bash +lizard add --repo YOUR_ORG/YOUR_REPO --name api-git --no-deploy --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api-git --json +``` + +このプロジェクトに Managed Postgres がない場合は、先に用意してください。この手順では、上と同じ Node.js の例を使用します。そのアプリがサブディレクトリにあるリポジトリ、または別ブランチのリポジトリでは、デプロイ前に設定してください: + +```bash +lizard service set api-git --set branch=YOUR_BRANCH --set rootDirectory=YOUR_APP_DIRECTORY --set containerPort=3000 --json +lizard redeploy --service api-git --json +``` + +リポジトリルートにあり、`main` 上にあるアプリでは、`service set` コマンドを省略してください。アプリケーションが別のポートを使う場合は、正しいポートを設定してください。リポジトリを Lizard から利用できない場合は、GitHub app を接続してください。この方法を無言でアップロードに置き換えないでください。 + +既存の GitHub サービスに対する後続の更新では、`lizard redeploy --service api-git` を使用するか、自動デプロイが有効な場合は追跡対象ブランチに push してください。`lizard up` は、サービスをアップロードソースに切り替えます。すでに稼働中のサービスでビルド設定を変更すると、そのサービス自身のビルドが発生することがあります。別のリクエストを行う前に、event を確認してください。 + + + +## 結果を確認する + +ビルドログとランタイムログは分けて読んでください: + +```bash +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +GitHub の方法では、`api` の代わりに `api-git` を使ってください。`APP_URL` を CLI が報告した HTTPS URL に設定し、次を実行します: + +```bash +curl --fail "$APP_URL/health" +curl --fail "$APP_URL/data" +``` + +最初のレスポンスは `App ready` です。2 つ目は `{"value":"database-connected"}` です。ビルドだけでは、データベース参照が解決されたことの証明にはなりません。この例が公開するのは、この固定されたデモ行だけであり、データベース管理 API ではありません。 + +このテストサービスでは、ランタイム再起動を確認してください: + +```bash +lizard restart --service api --json +``` + +サービスが `lizard ps --json` で `running` に戻るまで待ち、両方の HTTP リクエストを再実行してください。ランタイムログの tail は空の場合があります。アプリケーションの確認は HTTP レスポンスです。行は Managed Postgres に保存されており、サービスプロセスはそれを保存しません。既存データの再利用を確認するには、再起動前にデータベースエディタでデモ行を識別しやすい値に更新し、その後 `/data` がその値を返すことを確認してください。 + +`logs --json` はログの tail を返して終了します。実際のアプリケーションデータを変更する前に、[ストレージとリカバリ](/platform/storage-and-recovery) を読んでください。 + + + +## デプロイに失敗した場合 + +失敗したコマンドの終了 code と JSON エラーを使用してください。コンパイルエラー、終了するプロセス、到達できないポートでは、それぞれ異なる修正が必要です。[JSONと自動化](/cli/json) と [サービスが常にhealthyにならない](/deploy/troubleshooting/service-never-healthy) を参照してください。`redeploy` は新しいビルドであり、古いバージョンへのロールバックではありません。 + + + +## 制限とコスト + +エージェントは、人と同じ CLI を通じて課金対象リソースを作成できます。[limits](/platform/limits) と [pricing](https://lizard.build/pricing) を確認し、必要なプロジェクトとサービスに認証情報の範囲を限定してください。 + +確認済みバージョン、クラウド結果、残っている制限については、[シナリオテストの結果](/guides/validation) を参照してください。 diff --git a/_locales/ja/guides/deploy-mcp-server.mdx b/_locales/ja/guides/deploy-mcp-server.mdx new file mode 100644 index 0000000..1af8e91 --- /dev/null +++ b/_locales/ja/guides/deploy-mcp-server.mdx @@ -0,0 +1,116 @@ +--- +description: "Streamable HTTP、bearer token の検証、ヘルスエンドポイント、ツール呼び出しを検証するクライアントを備えたリモート MCP サーバーを Lizard でホストします。" +--- + + + +# リモート MCP サーバーをホストする + +クライアントがリモート URL を必要とする場合は、MCP サーバーを HTTP アプリケーションとしてデプロイします。この例では、1 つの算術ツールを提供し、bearer token を検証し、ヘルスエンドポイントを公開します。Streamable HTTP を使用します。ローカルの `stdio` サーバーだけでは、リモートクライアントに提供できません。 + + + +## 開始する前に + +Node.js 22、Lizard CLI、デプロイ可能なプロジェクト、設定済み bearer token を受け付ける MCP クライアントが必要です。この例では、ステートレスモードで `@modelcontextprotocol/sdk` 1.30.0 を使用します。OAuth ログイン、ブラウザーアクセス、または ID プロバイダーは提供しません。 + +実行可能なファイルは [remote-mcp-node](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/remote-mcp-node) にあります。チェックイン済みの lockfile を使用してください。ローカルのスモークテストでは、初期化、ツールの検出、ツール呼び出し、有効な token がない場合の拒否を確認します。デプロイの確認では、公開プロキシと TLS の経路も確認する必要があります。 + + + +## ローカルで実行する + +サンプルディレクトリから: + +```bash +npm ci +npm test +node issue-token.mjs +export MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" +export MCP_ALLOWED_HOSTS=127.0.0.1,localhost +npm start +``` + +生成された token は 1 時間後に期限切れになります。秘密署名鍵は保存されません。継続的なデプロイには、独自の token 発行およびローテーションの仕組みを使用し、その秘密鍵はサーバーの外部で管理してください。 + +別のターミナルで: + +```bash +export MCP_URL=http://127.0.0.1:8000/mcp +export MCP_TOKEN="$(cat .mcp-token)" +node client.mjs +``` + +クライアントは初期化、ツールの検出、結果 `5` を確認し、その後 `MCP initialize, tools/list and tools/call passed: 5` を出力します。`/health` は `ok` を返します。`/mcp` への、有効な token なしのリクエストは `401` を返します。 + + + +## アプリケーションをデプロイする + +サンプルの Dockerfile と lockfile はそのまま使ってください。それらを含むディレクトリから: + +```bash +lizard init --name mcp-example +lizard add --service mcp +lizard domain --service mcp --json +``` + +認証が必要だとコマンドに表示された場合は、`lizard login` でサインインしてください。`init` はプロジェクトをリンクし、`add` は指定した名前のサービスを作成します。domain コマンドは、デプロイ前にそのホスト名を割り当てます。返された `hostname` を以下で使用してください。`https://` やパスは付けないでください: + +```bash +lizard secrets set MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" --service mcp +lizard secrets set MCP_ALLOWED_HOSTS=YOUR_SERVICE_HOSTNAME --service mcp +``` + +最初のデプロイ前に両方の値を設定してください。その後、次を実行します: + +```bash +lizard up --service mcp --port 8000 +lizard logs --build --service mcp --json +lizard logs --service mcp --json +lizard ps --json +``` + +macOS で Lizard CLI 0.3.92 を使う場合は、アーカイブから AppleDouble メタデータを除外するために `COPYFILE_DISABLE=1 lizard up --service mcp --port 8000` を使用してください。後の CLI リリースでは、このアーカイブ修正が含まれている可能性があります。最終的なデプロイイベントと公開エンドポイントを確認してください。ビルド失敗後は、この CLI バージョンの終了コードだけに依存しないでください。`server.mjs` は `0.0.0.0` で待ち受け、`PORT` を読み取ります。デフォルトは 8000 です。deploy コマンドはサービスのポートを 8000 に設定します。公開鍵は複数行の環境変数値として設定してください。秘密署名鍵や token ファイルはアップロードしないでください。 + + + +## 公開エンドポイントを検証する + +`MCP_URL` を `https://YOUR_SERVICE_HOSTNAME/mcp` に設定し、クライアント環境に有効な token を保持したまま、`node client.mjs` を実行します。次の 3 つの結果をすべて確認してください: + +1. `/health` は HTTPS 経由で `200` を返す。 +2. `/mcp` は、有効な token を持たないクライアントを拒否する。 +3. 認証済みクライアントはツール一覧を取得し、`add` を呼び出して `5` を返す。 + +プロセスが正常であるだけでは、MCP ハンドシェイクやストリーミングされたレスポンスが公開プロキシ経由で機能していることの証明にはなりません。 + + + +## トラブルシューティング + +| 結果 | 確認 | +|---|---| +| 起動中にプロセスが終了する | `MCP_PUBLIC_KEY` には公開 PEM 鍵が含まれている必要があります。`MCP_ALLOWED_HOSTS` にはサービスのホスト名が含まれている必要があります。 | +| `401` | token は RS256 を使用し、issuer と audience `mcp-example` が一致し、期限切れであってはいけません。 | +| `403` | リクエストのホスト名を `MCP_ALLOWED_HOSTS` と一致させてください。この例ではブラウザーの origin は有効化されていません。 | +| 有効な token で `405` | このステートレス MCP エンドポイントは、POST を通じてプロトコルリクエストを受け付けます。MCP クライアントを使用してください。token なしのブラウザー GET は、まず `401` を返します。 | +| ローカルテストは成功するがリモート呼び出しが失敗する | port、HTTPS、レスポンスストリーミング、プロキシのタイムアウトを確認してください。 | + + + +## 制限とコスト + +この例では、ユーザーセッションや永続ファイルをサーバーメモリに保持しません。長期的なアプリケーション状態にはデータベースを追加し、非公開ツールを公開する前にユーザーごとのアクセスを確認してください。OAuth ディスカバリーや対話的ログインを必要とするクライアントには、このテスト token を配布する代わりに、サポートされている OAuth プロバイダーを追加してください。 + +HTTP プロセスは呼び出しの間もアクティブなままの場合があります。[pricing](https://lizard.build/pricing)、[limits](/platform/limits)、測定された CPU/メモリを確認してください。リクエストキューが空でも、料金が発生していないことを意味しません。 + + + +## 次のステップ + +- [環境変数リファレンス](/variables/references) +- [デプロイの復旧](/concepts/deployments) +- [MCP TypeScript SDK サーバーガイド](https://ts.sdk.modelcontextprotocol.io/server) + +確認済みバージョン、クラウドでの結果、残っている制限については、[シナリオテスト結果](/guides/validation) を参照してください。 diff --git a/_locales/ja/guides/flowise.mdx b/_locales/ja/guides/flowise.mdx new file mode 100644 index 0000000..1b128f3 --- /dev/null +++ b/_locales/ja/guides/flowise.mdx @@ -0,0 +1,165 @@ +--- +description: "PostgreSQL で Flowise をデプロイし、その認証情報の暗号化キーを保持して、再起動やアップグレード後に保存済みフローを確認します。" +--- + + + +# PostgreSQL で Flowise を実行する + +このガイドでは、Lizard 上で 1 つの Flowise サービスを実行し、フロー、アカウント、暗号化された認証情報に PostgreSQL を使用します。正確な npm バージョンをビルドし、暗号化キーをサービスシークレットとして設定します。 + +基本構成は API を使用するフローを対象としています。アップロードしたファイルやローカルのベクターストアには別途永続ストレージが必要です。これらの機能を使用する前に [ファイルストレージ](#file-storage) を参照してください。 + + + +## 前提条件 + +- アプリホスティングと Managed Postgres を利用できる Lizard アカウント。 +- お使いのコンピューターに Node.js、npm、OpenSSL がインストールされていること。 +- Flowise のワークロードに十分なメモリ。テストサービスでは 4 GiB を使用します。 + +Lizard CLI をインストールし、ブラウザログインを完了します: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + + + +## プロジェクトを作成する + +```bash +mkdir flowise-on-lizard +cd flowise-on-lizard +lizard init --name flowise-on-lizard +lizard add postgres --name flowise-db +lizard add --service flowise +``` + +ワークスペースを選択する必要がある場合は、`--workspace ` と `lizard init` を使用します。データベースが実行中になるまで待ちます。 + + + +## 固定した Flowise バージョンをビルドする + +以下の内容で `Dockerfile` を作成します。これは Flowise の Docker ビルドに従い、npm パッケージを `3.1.4` に固定します: + +```dockerfile +FROM node:24-alpine AS build +RUN apk add --no-cache git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev +ENV PUPPETEER_SKIP_DOWNLOAD=true +RUN npm install -g flowise@3.1.4 --legacy-peer-deps + +FROM node:24-alpine +RUN apk add --no-cache chromium git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev curl +ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser +COPY --from=build /usr/local/lib/node_modules /usr/local/lib/node_modules +COPY --from=build /usr/local/bin /usr/local/bin +RUN chown -R node:node /usr/local/lib/node_modules /usr/local/bin +USER node +EXPOSE 3000 +ENTRYPOINT ["flowise", "start"] +``` + +`--legacy-peer-deps` は、古いネイティブ SQLite 依存関係を含むオプションの peer 統合をインストールしないようにします。このレシピは PostgreSQL と API ベースのフローを対象としています。それらを必要とするノード向けの追加依存関係は、別途インストールしてテストしてください。 + +Dockerfile を明示的に選択します: + +```bash +lizard service set flowise --set dockerfilePath=Dockerfile +``` + + + +## PostgreSQL と暗号化を設定する + +Flowise サービスでデータベース変数を参照します: + +```bash +lizard secrets set \ + DATABASE_TYPE=postgres \ + DATABASE_HOST='${{flowise-db.PGHOST}}' \ + DATABASE_PORT='${{flowise-db.PGPORT}}' \ + DATABASE_USER='${{flowise-db.PGUSER}}' \ + DATABASE_PASSWORD='${{flowise-db.PGPASSWORD}}' \ + DATABASE_NAME='${{flowise-db.PGDATABASE}}' \ + --service flowise +``` + +シェルが参照を展開しないよう、シングルクォートはそのままにしてください。Lizard はサービスの起動時にそれらを解決します。 + +セットアップ時に次のシークレットを 1 度だけ生成します: + +```bash +lizard secrets set \ + FLOWISE_SECRETKEY_OVERWRITE="$(openssl rand -hex 32)" \ + JWT_AUTH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + JWT_REFRESH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + EXPRESS_SESSION_SECRET="$(openssl rand -hex 32)" \ + TOKEN_HASH_SECRET="$(openssl rand -hex 32)" \ + SECURE_COOKIES=true \ + --service flowise +``` + +これらの値は安全な場所にコピーを保管してください。特に `FLOWISE_SECRETKEY_OVERWRITE` は保持してください。Flowise は、PostgreSQL にすでに保存されている認証情報を復号するために同じキーを必要とします。再起動、再デプロイ、アップグレードの際にシークレットを再生成しないでください。 + + + +## デプロイしてアカウントを作成する + +```bash +lizard up --service flowise --port 3000 +``` + +最初のビルドでは Flowise とその依存関係をインストールするため、数分かかることがあります。デプロイで返された HTTPS URL を開き、URL を共有する前に最初の owner アカウントを作成してください。エディターにサインインします。 + +Flowise が生成するリンク用に公開 URL を設定します。例は実際の HTTPS URL に置き換えてください: + +```bash +lizard secrets set APP_URL=https://YOUR-SERVICE.onlizard.com --service flowise +``` + +この変更によりサービスが再起動します。パスワードリセットや招待メールが必要な場合は、SMTP を別途設定してください。 + + + +## 永続性を確認する + +フローを作成して保存します。テスト用の認証情報を追加し、その後 Flowise を再起動します: + +```bash +lizard restart --service flowise +``` + +サービスが実行中になるまで待ち、再度サインインして、フローと認証情報が残っていることを確認します。認証情報を使用するフローを実行し、Flowise がそれを引き続き復号できることを確認してください。再デプロイ後も同じ確認を繰り返します: + +```bash +lizard redeploy --service flowise +``` + +PostgreSQL と暗号化キーの両方をバックアップしてください。キーがないデータベースバックアップでは、保存済みの認証情報を復元できません。 + + + +## ファイルストレージ + +PostgreSQL は、Flowise が書き込むすべてのファイルを保存するわけではありません。このセットアップでは永続ファイルボリュームをマウントしないため、ローカルアップロード、ローカルベクターデータベース、ファイルログはコンテナが置き換えられると消える可能性があります。 + +アップロードやドキュメントワークフローを使用する前に、Flowise の [ストレージ変数](https://docs.flowiseai.com/configuration/environment-variables) を使用してプライベート S3 バケットを設定してください。`STORAGE_TYPE=s3`、`S3_STORAGE_BUCKET_NAME`、`S3_STORAGE_ACCESS_KEY_ID`、`S3_STORAGE_SECRET_ACCESS_KEY`、`S3_STORAGE_REGION` を設定します。S3 互換プロバイダーの場合は、`S3_ENDPOINT_URL` と `S3_FORCE_PATH_STYLE=true` も設定します。 + +Lizard の Managed Object Storage は、公開読み取りの `default` バケットを作成します。アクセス設定を先に変更せずに、そのバケットへ非公開の Flowise ドキュメントを保存しないでください。上記の PostgreSQL セットアップでは、ファイルストレージ、ローカルベクターストア、キューワーカーはプロビジョニングもテストも行いません。 + + + +## トラブルシューティングとアップデート + +```bash +lizard events --service flowise +lizard logs --build --service flowise +lizard logs --service flowise +``` + +初回デプロイで、イメージの pull 中にタイムアウトした場合は、`lizard events` を確認してください。コンテナの起動後に、`lizard up --service flowise --port 3000` を再試行します。これまでにビルド成功が 1 度もないサービスでは、まだ `lizard redeploy` を使用できません。 + +アップデートする場合は、データベースをバックアップし、Flowise のリリースノートを読み、Dockerfile の npm バージョンを変更してから、`lizard up` で再度アップロードします。更新に依存する前に、新しいバージョンを確認し、永続性チェックを実行してください。 diff --git a/_locales/ja/guides/index.mdx b/_locales/ja/guides/index.mdx new file mode 100644 index 0000000..701dceb --- /dev/null +++ b/_locales/ja/guides/index.mdx @@ -0,0 +1,25 @@ +--- +description: "コーディングエージェントからのデプロイ、リモート MCP サーバーのホスティング、Telegram ワーカーの実行、サンドボックスファイルの保持に関するタスクガイド。" +--- + + + +# ガイド + +実行したいワークロードを選択してください。各ガイドではセットアップ、確認事項、制限事項を説明しています。フラグの正確な構文が必要な場合は、コマンドリファレンスを使用してください。 + +| タスク | ガイド | +|---|---| +| Claude Code、Codex、または Cursor が作成したアプリをデプロイする | [コーディングエージェントからデプロイする](/guides/deploy-from-coding-agent) | +| MCP クライアントにリモート HTTPS エンドポイントを提供する | [リモート MCP サーバーをホストする](/guides/deploy-mcp-server) | +| 1 つの Telegram ロングポーリングプロセスを実行し続ける | [Telegram bot を実行する](/guides/telegram-bot) | +| HTTP リスナーなしでキューされたジョブを処理する | [バックグラウンドワーカー](/deploy/workers) | +| 別個の Linux ゲストでコードを実行する | [Sandboxes クイックスタート](/sandboxes/quickstart) | +| PostgreSQL で Web サイト分析を収集する | [Umami を実行する](/guides/umami) | +| PostgreSQL で Flowise フローと暗号化された認証情報を保持する | [Flowise を実行する](/guides/flowise) | +| 後のサンドボックスでファイルを再利用する | [Persistent Volumes](/sandboxes/volumes) | + +リソースを選ぶときは、[制限](/platform/limits)、[ストレージと復旧](/platform/storage-and-recovery)、[既知の問題](/platform/known-issues)を確認してください。 + +テスト済みバージョン、クラウドでの確認、残っているギャップについては、[シナリオテスト結果](/guides/validation)をお読みください。 + diff --git a/_locales/ja/guides/telegram-bot.mdx b/_locales/ja/guides/telegram-bot.mdx new file mode 100644 index 0000000..30648e4 --- /dev/null +++ b/_locales/ja/guides/telegram-bot.mdx @@ -0,0 +1,101 @@ +--- +description: "Telegram のロングポーリング bot を Lizard worker として実行します。トークンを設定し、HTTP ルーティングを無効にし、レプリカを 1 つに保ち、メッセージと再試行を確認します。" +--- + + + +# Telegram bot を実行する + +ロングポーリング bot はバックグラウンド worker です。Telegram に更新を問い合わせるため、公開 HTTP エンドポイントは不要です。`containerPort=0` と、bot トークンごとに 1 つのレプリカで実行してください。 + +**テスト状況:** モック化した Telegram レスポンスを使った 7 件のローカルテストは成功しています。クラウド上の実際の bot では、このガイドをまだ確認していません。実運用の前に、別のテスト用 bot を使用し、以下のメッセージ確認と再起動確認を完了してください。[シナリオテスト結果](/guides/validation)を参照してください。 + + + +## 始める前に + +BotFather で bot を作成し、そのトークンは非公開にしてください。Python 3.13、Lizard CLI、およびデプロイ可能なプロジェクトが必要です。ロングポーリングを使う bot には有効な webhook があってはいけません。更新の受信方法を変更する前に、現在の設定を確認してください。 + +[サンプルファイル](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/telegram-worker)には、`worker.py`、Dockerfile、ローカル unit test が含まれています。テストは Telegram を呼び出しません。echo handler は offset をメモリ内に保存するため、厳密な exactly-once 処理システムではありません。 + + + +## ローカルで確認する + +サンプルディレクトリで次を実行します: + +```bash +python3 -m unittest -v +``` + +この確認では、テキスト返信、無視される更新、空のポーリング、送信失敗を対象にしています。返信を送るつもりがある場合に限り、`TELEGRAM_BOT_TOKEN` を設定して bot をローカルで実行してください。ホストされた worker を開始する前に、そのローカルプロセスを停止してください。 + + + +## worker としてデプロイする + +```bash +lizard init --name telegram-bot +lizard add --service bot +``` + +コマンドで認証が必要と表示された場合は、`lizard login` でサインインしてください。デプロイ前に、**bot service** に `TELEGRAM_BOT_TOKEN` を設定してください。ダッシュボードの変数エディタを使うことも、値をローカルの `.env` ファイルに入れてインポートすることもできます: + +```bash +lizard secrets import --service bot < .env +lizard run --service bot -- python3 check_bot.py +lizard up --service bot --port 0 +``` + +事前チェックでは `getMe` でトークンを確認し、有効な webhook を持つ bot は拒否されます。その webhook は削除も変更もされません。2 つ目のポーリングプロセスも競合する可能性があります。デプロイ前に、ローカルで動いているコピーがあれば停止してください。 + +このサンプルでは、アップロード対象から `.env*` を除外しています。トークンをソースファイルやスクリーンショットに含めないでください。macOS で Lizard CLI 0.3.92 を使う場合は、アップロードコマンドの前に `COPYFILE_DISABLE=1` を付けてください。コマンドが正常終了しても、最後のデプロイイベントとログを確認してください。 + +既存の service の場合は、worker mode を明示的に設定してください: + +```bash +lizard service set bot --set containerPort=0 +``` + +実行中の service で worker mode を変更した後は、`lizard redeploy --service bot` で反映してください。別の build を要求する前に、デプロイイベントを確認してください。worker mode では HTTP ポートチェックとロードバランサーのルートをスキップします。このプロセスを HTTP アプリのように見せるためだけにダミーの web server を追加しないでください。 + + + +## 結果を確認する + +```bash +lizard ps --json +lizard logs --service bot --json +lizard events --json +``` + +ログには `Telegram worker started` が表示されるはずです。bot にメッセージを送信し、echo 返信が 1 回だけ返ることを確認してください。その後、承認されたテスト時間帯に worker を停止して再起動し、再接続することを確認してください。実行中と表示されている worker でも、このアプリケーションレベルの確認は必要です。 + + + +## よくある失敗 + +| 症状 | 確認事項 | +|---|---| +| プロセスがすぐに終了する | 使用する service に `TELEGRAM_BOT_TOKEN` を設定してください。 | +| HTTP ヘルスチェックがいつまでも通らない | worker mode では `containerPort=0` を使う必要があります。 | +| 更新が止まる、または競合エラーが表示される | このトークンを使うポーリングプロセスは 1 つだけにしてください。ローカルプロセス、別のレプリカ、有効な webhook がないか確認してください。 | +| 障害後に返信が繰り返される | このデモは offset を永続化せず、update ID の重複排除も行いません。取り消し不能な操作を扱う前に、永続的な冪等性を追加してください。 | +| 再試行が頻繁に発生する | ネットワークアクセス、トークンの有効性、Telegram の制限、handler を確認してください。リクエスト URL は出力しないでください。トークンが含まれています。 | + + + +## 状態とコスト + +永続的な bot 状態が必要な場合は、[Managed Postgres](/addons/postgres) に接続してください。処理済み update ID を保存し、handler を再試行しても安全になるようにしてください。ロングポーリングでは、メッセージの間も worker がアクティブなままになることがあります。見積もりはメッセージ数だけではなく、[pricing](https://lizard.build/pricing) と実際のリソース使用量に基づいて行ってください。 + + + +## 関連ガイド + +- [バックグラウンド worker](/deploy/workers) +- [ログ](/observability/logs) +- [制限](/platform/limits) +- [Telegram getUpdates リファレンス](https://core.telegram.org/bots/api#getupdates) + +確認済みバージョン、クラウド結果、残っている制限については、[シナリオテスト結果](/guides/validation)を参照してください。 diff --git a/_locales/ja/guides/umami.mdx b/_locales/ja/guides/umami.mdx new file mode 100644 index 0000000..6ecc7cd --- /dev/null +++ b/_locales/ja/guides/umami.mdx @@ -0,0 +1,122 @@ +--- +description: "Managed Postgres とともに Umami をデプロイし、暗号化シークレットを設定して、再起動と再デプロイ後にアナリティクスを確認します。" +--- + + + +# Umami を実行する + +このガイドでは、公式の Umami Docker イメージを Lizard 上で、別個の PostgreSQL データベースとともに実行します。Lizard CLI を使って小さなローカル Dockerfile をデプロイし、HTTPS 経由で Umami を公開します。 + + + +## 前提条件 + +- アプリホスティングと Managed Postgres にアクセスできる Lizard アカウント。 +- お使いのコンピューターに Node.js と npm、およびシークレット生成用の OpenSSL。 + +Lizard CLI をインストールしてログインします: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +続行する前に、ブラウザーでログインを完了してください。以下のコマンドは Lizard CLI 0.3.95 と Umami 3.3.1 でテストされています。 + + + +## プロジェクトとデータベースを作成する + +このデプロイ用に新しいディレクトリを使用します: + +```bash +mkdir umami-on-lizard +cd umami-on-lizard +lizard init --name umami-on-lizard +lizard add postgres --name umami-db +lizard add --service umami +``` + +複数のワークスペースに所属している場合は、1 つを選ぶために `lizard init` に `--workspace ` を渡してください。Umami をデプロイする前に、データベースが `running` になるまで待ちます。 + + + +## イメージとシークレットを設定する + +`Dockerfile` という名前のファイルを作成します: + +```dockerfile +FROM ghcr.io/umami-software/umami:3.3.1 +EXPOSE 3000 +``` + +このファイルを記述どおりに使うよう Lizard に指定します: + +```bash +lizard service set umami --set dockerfilePath=Dockerfile +``` + +データベースを接続し、2 つの別々のシークレットを生成します: + +```bash +lizard secrets set \ + DATABASE_URL='${{umami-db.DATABASE_URL}}' \ + APP_SECRET="$(openssl rand -hex 32)" \ + TWO_FACTOR_ENCRYPTION_KEY="$(openssl rand -hex 32)" \ + --service umami +``` + +データベース参照のまわりのシングルクォートはそのままにしてください: サービスの起動時に Lizard がそれを解決します。これらの値はこのサービスに属するため、プロジェクト内のほかのアプリはそれらを受け取りません。 + +生成した両方のシークレットはパスワードマネージャーに保存してください。セットアップ時に一度だけ設定し、再起動やアップグレードの際に再生成しないでください。`TWO_FACTOR_ENCRYPTION_KEY` は二要素認証に必要です。 + + + +## デプロイしてサインインする + +Dockerfile を含むディレクトリから、次を実行します: + +```bash +lizard up --service umami --port 3000 +``` + +Umami のイメージは起動時にデータベースのセットアップとマイグレーションを実行します。このイメージには別個のマイグレーションコマンドは不要です。 + +デプロイで返された HTTPS URL を開きます。新しい Umami 3.3.1 データベースでは、ユーザー名 `admin` とパスワード `umami` でサインインし、URL を共有する前にプロフィールですぐにパスワードを変更してください。Web サイトを追加し、そのトラッキングスクリプトを自分が管理するページにインストールします。 + +デプロイに失敗した場合は、そのステータスとログを確認します: + +```bash +lizard events --service umami +lizard logs --build --service umami +lizard logs --service umami +``` + +最初の起動がタイムアウトする場合は、コンテナーの準備状況について `lizard events` を確認してください。コンテナーが起動したら、`lizard up --service umami --port 3000` でアップロードを再試行します。 + + + +## データの永続性を確認する + +トラッキング対象のページにアクセスし、Umami がページビューを記録することを確認します。アプリケーションを再起動します: + +```bash +lizard restart --service umami +``` + +サービスが再び実行状態になるまで待ちます。新しいパスワードでサインインでき、Web サイトとページビューが残っていることを確認してください。次に、再デプロイ後にも同じ確認を繰り返します: + +```bash +lizard redeploy --service umami +``` + +Umami はアカウント、Web サイト設定、アナリティクスを PostgreSQL に保存します。これらの記録のために、アプリケーションにファイルボリュームは必要ありません。アプリを置き換えたりアップグレードしたりするときは、データベースと暗号化シークレットを維持してください。再起動の確認は、検証済みのデータベースのバックアップおよび復元計画の代わりにはなりません。 + + + +## Umami を更新する + +アップグレード前に PostgreSQL をバックアップし、リリースノートを読んでください。ローカル Dockerfile のイメージタグを変更してから、再度 `lizard up --service umami --port 3000` を実行します。このアップロードベースのセットアップでは、`lizard redeploy` は最後にアップロードしたファイルを再ビルドします。ローカルの編集内容はアップロードしません。 + +データベースアクセスについては [Lizard の PostgreSQL ガイド](https://lizard.build/docs/addons/postgres/)、バックアップ計画については [ストレージとリカバリー](https://lizard.build/docs/platform/storage-and-recovery/) を参照してください。 diff --git a/_locales/ja/guides/validation.mdx b/_locales/ja/guides/validation.mdx new file mode 100644 index 0000000..d6d7717 --- /dev/null +++ b/_locales/ja/guides/validation.mdx @@ -0,0 +1,39 @@ +--- +description: "MCP、coding-agent、Redis worker、Telegram ガイドについて、クラウド結果、再起動時の挙動、検証済みバージョン、残っている制限を確認します。" +--- + + + +# シナリオガイドのテスト結果 + +2026-09-07 に、Lizard CLI 0.3.92 を使って、これらのガイドを別のテストプロジェクトで確認しました。アプリケーションの確認はビルドステータスとは別です。テストではガイドのコマンドを使用し、GitHub の例では別のプロジェクト名とドキュメント用テストブランチを使いました。 + +| ガイド | 結果 | チェック | +|---|---|---| +| [Remote MCP](/guides/deploy-mcp-server) | ローカルおよびクラウドで合格 | Health 200; トークンなしおよび無効なトークン 401; 認証済み GET 405; 拒否された Origin 403; initialize、tools/list、tools/call; 公開 HTTPS 経由の結果 `5` | +| [コーディング エージェント: アップロード](/guides/deploy-from-coding-agent) | 合格 | `lizard up`、health 200、データベースを使用したレスポンス 200、未知のルート 404; 更新された Postgres 行はサービス再起動後も保持された | +| [コーディング エージェント: GitHub](/guides/deploy-from-coding-agent) | 合格 | リポジトリは `--no-deploy` で接続; ブランチ、ルートディレクトリ、環境は `redeploy` の前に設定; 公開アプリは同じ既存の Postgres 行を読み取った | +| [Redis worker](/deploy/workers) | 合格 | ポート 0; enqueue と result; result は再起動後も保持; 再起動後の新しいジョブ; 完了していない processing エントリは起動時に復旧 | +| [Telegram bot](/guides/telegram-bot) | ローカルテストのみ | 7 つのモックテストで updates、送信失敗、トークン確認、webhook 拒否をカバー。実際のトークン、chat、クラウドでの echo テストはまだ必要 | + + + +## バージョン + +MCP コンテナは Node.js 22.23.2 と MCP TypeScript SDK 1.30.0 で動作しました。coding-agent の例では `pg` 8.16.3 を使用し、PostgreSQL 18.4 で動作する Managed Postgres に接続しました。worker コンテナは Python 3.13.15 と redis-py 6.4.0 で動作しました。依存関係の lockfile または厳密な requirements は各 example にあります。 + + + +## 対象範囲 + +MCP の確認は、この example のステートレスな HTTP transport と固定 bearer token を対象にしています。OAuth 互換性、ブラウザ対応、長時間のストリーミング、負荷容量は確認していません。トークンは 1 時間後に期限切れになります。 + +GitHub の確認では、ドキュメント用ブランチと `_examples/agent-app` ディレクトリを使用しました。明示的な redeploy はテストしましたが、すべての private-repository 権限設定や webhook event はテストしていません。 + +Redis 復旧の確認では、単一の consumer を再起動する前に、完了していない processing エントリを事前投入しました。Redis 障害、複数 worker、外部効果の exactly-once はテストしていません。データベースの確認は、アプリケーション再起動をまたいだ永続性を示すものであり、バックアップや災害復旧を示すものではありません。 + +テストサービスの runtime log tail は当初空でした。その後、live worker log stream で新しく処理されたジョブが配信されました。完了基準としては HTTP、MCP client、job-result の確認を使用してください。log tail が空であることだけでは、成功も失敗も示せません。 + +Telegram の example は cloud-verified としてはマークされていません。preflight ではボットの webhook を変更せずに `getMe` と `getWebhookInfo` を読み取ります。polling loop を有効にする前に、別のテスト用 bot を使用してください。 + +CLI アーカイブと failed-build の exit-code 制限については [フレームワークのテスト結果](/framework-guides/validation) の別の 16 レシピの framework バッチと、[known issues](/platform/known-issues) を参照してください。 diff --git a/_locales/ja/index.mdx b/_locales/ja/index.mdx new file mode 100644 index 0000000..6542d53 --- /dev/null +++ b/_locales/ja/index.mdx @@ -0,0 +1,57 @@ +--- +description: "アプリをデプロイし、ワーカーを実行し、Managed Postgres を接続し、または Sandboxes でコードを実行します。タスクを選び、ガイドに従い、制限を確認してください。" +--- + + + +# Lizard ドキュメント + +Lizard は GitHub リポジトリまたはローカルフォルダからアプリケーションをビルドして実行します。Lizard CLI またはダッシュボードを使って、Web サービスをデプロイし、バックグラウンドワーカーを実行し、Managed Postgres または Managed Redis を接続し、ログを確認できます。Lizard SDK を使うと、コード実行用の Sandboxes を作成できます。 + + + +## タスクを選ぶ + +| やりたいこと | ここから開始 | +|---|---| +| 最初のアプリをデプロイする | [App quickstart](/getting-started) | +| Next.js、React、Vue、または Python アプリをデプロイする | [フレームワーク guides](/framework-guides) | +| Claude Code または別のコーディングエージェントからデプロイする | [コーディング エージェント ガイド](/guides/deploy-from-coding-agent) | +| リモート MCP サーバーをホストする | [Remote MCP guide](/guides/deploy-mcp-server) | +| Telegram bot を動かし続ける | [Telegramワーカーガイド](/guides/telegram-bot) | +| データベースを接続する | [Managed Postgres](/addons/postgres) | +| 生成されたコードを別環境で実行する | [Sandboxes quickstart](/sandboxes/quickstart) | +| sandbox 終了後もファイルを保持する | [Persistent Volumes](/sandboxes/volumes) | + + + +## アプリをデプロイする + +Lizard CLI をインストールしてサインインし、アクセス可能なリポジトリをデプロイします: + +```bash +npm install -g @lizard-build/cli +lizard login +lizard add -r your-org/your-app +``` + +Lizard はサーバー上でイメージをビルドするため、この方法ではローカルの Docker は不要です。[lizardpack](/concepts/build-pipeline) がサポート対象のプロジェクトを検出します。特別なビルド要件があるプロジェクトでは、明示的なコマンドまたは Dockerfile を使用できます。ビルドログを確認し、デプロイ後にアプリケーション URL を検証してください。 + + + +## リソースを理解する + +**workspace** はメンバーとプロジェクトをまとめる単位です。**project** はサービス、データベース、Sandboxes をまとめる単位です。**service** はアプリケーションまたはワーカーを実行します。Managed Postgres、Managed Redis、Managed Object Storage は、アプリケーションが環境参照を通じて接続するデータサービスを提供します。 + +アプリと Sandboxes では、ランタイムとストレージのルールが異なります。リソースのサイズ、有効期間、またはデータ保持に依存する前に、[limits](/platform/limits) と [ストレージとリカバリ](/platform/storage-and-recovery) を確認してください。 + + + +## 適切な詳細レベルを見つける + +- [Guides](/guides) は、セットアップから結果確認までタスク全体を扱います。 +- [フレームワーク guides](/framework-guides) は、各スタック向けのビルドコマンド、アダプター、ポート、確認項目を示します。 +- [Core concepts](/concepts/architecture) は、プロジェクト、ビルド、デプロイについて説明します。 +- [Lizard CLIリファレンス](/cli) は、コマンド、フラグ、終了コードを一覧表示します。 +- [Troubleshooting](/deploy/troubleshooting/service-never-healthy) は、起動失敗の診断に役立ちます。 +- [Known issues](/platform/known-issues) は、リリース前に確認すべき制限事項と復旧ケースを記録しています。 diff --git a/_locales/ja/manifest.json b/_locales/ja/manifest.json new file mode 100644 index 0000000..1d9970c --- /dev/null +++ b/_locales/ja/manifest.json @@ -0,0 +1,576 @@ +{ + "locale": "ja", + "status": "published", + "pages": [ + { + "path": "addons/index.mdx", + "sourceSha256": "a364ec2783f0102fb3067cc844c4db4e6709b3bc522508dea3ccc67aae830ae0", + "translationSha256": "dd387e42c665ce7c37854c5df624cfbb93381559483daefd785ee1610e799600", + "status": "published" + }, + { + "path": "addons/postgres.mdx", + "sourceSha256": "78346399743959929c09c87d1d98a7e8274d93c1e21a764df94a02b613ac0d09", + "translationSha256": "b42028f9cc2d6418a5a7b385eb91a8600656643ed0b6fba595224c63254a1c98", + "status": "published" + }, + { + "path": "addons/redis.mdx", + "sourceSha256": "5c295a88f06837b2c581b62b2a8787dec1f8da73c77cdf1c8a8b051d5fdd9c19", + "translationSha256": "6f320d7204a3a8d5bc544642a6ffc3cceb5698a6c29053f8ea1665c6376f64e3", + "status": "published" + }, + { + "path": "addons/storage.mdx", + "sourceSha256": "60eb80b5a079fc37daa87d064bbb6824ff8061682f54671567389b41ea9a2e3a", + "translationSha256": "3b6783afdb0a950182407cd7b9c04bccbbd758690c706004f37dfcdc15000ea8", + "status": "published" + }, + { + "path": "agents.mdx", + "sourceSha256": "6d12cad052e608f5685ce8a08051d0b5c9d0f0981c06ddf7aa422479f8a6a20a", + "translationSha256": "6ba2f92e3c5dfee278f72fe975546af15f1f3b150c4dde77e422c89b2d15d5b1", + "status": "published" + }, + { + "path": "cli/add.mdx", + "sourceSha256": "da07da89b28ff85a02dd9afd621d75c935a8e47e26c3bb1bebdeb4fae7d935b7", + "translationSha256": "0e17b16a62822f0fa597f93a5c2f2280f10e230d64cc4306f4f0870351ed4de1", + "status": "published" + }, + { + "path": "cli/config.mdx", + "sourceSha256": "7ff4c3a6d511e1bf7086f6ea11f47af473c9fd6d15865808bdd0548c265bcd56", + "translationSha256": "b5dbd242fb310e0ef9443bd97955cfdba25173efd324fa255d4916857b27d32e", + "status": "published" + }, + { + "path": "cli/docs.mdx", + "sourceSha256": "2f99ebda3a4339d975e1b12c6e8949b4aac33e2b6b4284cfbf5944b274936b83", + "translationSha256": "f50ecf2f50daae404f259068890677e4f4351fa2200f6c73557e1ff9973d8c74", + "status": "published" + }, + { + "path": "cli/domain.mdx", + "sourceSha256": "9d4d1e70a6b4078de6486abf9f3f8c679b922e117823232d41df0e403918458f", + "translationSha256": "676a831111967b79cbbf371eee90497a8bb5e5a36eae90718ecbc11681b98218", + "status": "published" + }, + { + "path": "cli/events.mdx", + "sourceSha256": "ce890a024e8b37c7566a3f23d74fe867554aacbcf034103a64d48ba910b4aa4d", + "translationSha256": "0d33592fe0bf31739baa7ea96109a6d9d8e7c8dcb0407dfa945a90975e3aca9f", + "status": "published" + }, + { + "path": "cli/git.mdx", + "sourceSha256": "d41bde854400c6879516d11f06a0792adad0491f294addcb6a3fbbaca140d2f5", + "translationSha256": "8430e12252da33829df2f15515a59af57fe17152b3c9faa32af8b94a6c3c4001", + "status": "published" + }, + { + "path": "cli/index.mdx", + "sourceSha256": "b9f5bb24b661770d8b5fe2916ea43890af08cafc17f32ccd0e49d2e56a0df422", + "translationSha256": "51ac7c26459d9bb1742eac9e9b8ef841d55e5fd3eb09976d94eaf233fdca0dd5", + "status": "published" + }, + { + "path": "cli/init.mdx", + "sourceSha256": "9ea4e3b5641acc86a3bb0e7013f74cd03df18d64a150858f33cc4220e987cfc7", + "translationSha256": "3c6cb5aceb24b728dfeb4c73f51a8051cc136fa2e61e8ec167717fb366edf32d", + "status": "published" + }, + { + "path": "cli/json.mdx", + "sourceSha256": "0db2f5c74b3d7d55b467f5235d38805f5ba531b3b56b60eeb591722b89634798", + "translationSha256": "5ccaf0d4c52b6e29e9c71621085605b14544e8a3dba0cab5d9a0222df15a3b66", + "status": "published" + }, + { + "path": "cli/link.mdx", + "sourceSha256": "c830b5269697edcce4a1344de712a26319d60dbb73f9aee71f905da45f301c90", + "translationSha256": "4702b55c6e74f25308fd782c201a4a81a46a2b6b2fc2d318f589f8232bb08c09", + "status": "published" + }, + { + "path": "cli/login.mdx", + "sourceSha256": "732fd0d32942e45da0f61325478ac2853710161f8d8dd9cbd874b192ddd41220", + "translationSha256": "62f767cab8eba4388e278b77efd69827f68f7d03354f211a4fb165e40954a363", + "status": "published" + }, + { + "path": "cli/logout.mdx", + "sourceSha256": "a8e49ead7c934a4c29d44421349bd46d3f7f1cc81dbde03ef4350d10cbf12e03", + "translationSha256": "fa78e705fce1f3f4082347f7fbdcbab0111427c7acd20b57de05745d498d61f8", + "status": "published" + }, + { + "path": "cli/logs.mdx", + "sourceSha256": "deebb5f030fb9b3a36000036f9b8f829fc8319cd0c559ebe0f528f175d5eb384", + "translationSha256": "477115f9d10d53b13b6184fba3b0a6c97ee9f06614cda4b1b8608ac3a925d4b2", + "status": "published" + }, + { + "path": "cli/metrics.mdx", + "sourceSha256": "dcfa3c003c126ccbc276d2423d5d8fab30adfb685459c4cf546cc53ed02d3429", + "translationSha256": "e5e4317040aefa1702e58a7a007ca5b407a0e8714f79cf08c224233d66e0e580", + "status": "published" + }, + { + "path": "cli/open.mdx", + "sourceSha256": "34659aaba345efeca309eded62ca791414e7f2cac10aa6a66b1fc81a6adcc7cd", + "translationSha256": "422dbee9313deacb7c2f91ebab492ddf623c170c04d20ec8f29f0403fe4e7f0e", + "status": "published" + }, + { + "path": "cli/port.mdx", + "sourceSha256": "925f588fe174b968738163a0c064af2090b9d4489dd82a75a5b111d8c002f8e8", + "translationSha256": "fcf48fd22fd94eb761b5450242e89a26eaf73f01b9f3e1c4c1dad685f2ef5e8b", + "status": "published" + }, + { + "path": "cli/project.mdx", + "sourceSha256": "3cd89738f9965ece2a6ec8158963cfe3d0f118bf81334dde58792ac858890521", + "translationSha256": "8601182d1662c3d0d35d4a07abcf2ef0917d307e40914994d4565842ae2bbf57", + "status": "published" + }, + { + "path": "cli/ps.mdx", + "sourceSha256": "7cae9f4efdd03bd9cc38affa13ce3537d8f6a6cb8ec4a3e12748235a29afb7d1", + "translationSha256": "f747a6d784694568a72a3d2d191590b0b8aec5fcd949c5d2b16f751d14adbba6", + "status": "published" + }, + { + "path": "cli/redeploy.mdx", + "sourceSha256": "69e3567d19d1eee5ecb88848519c871170982cd8bdae0cc832848425c00976f4", + "translationSha256": "756f4531f9868ad225fcd65c038a13a66d628037acd583ee7848a6007785c952", + "status": "published" + }, + { + "path": "cli/regions.mdx", + "sourceSha256": "fb4374ff44f0cb307cda3b11a32d2af140628aecefcc72648c8bd4fac79a0390", + "translationSha256": "f4815e4abb2de861aebab8df053caa5d26ad58ad0f809836370bb11553b30b18", + "status": "published" + }, + { + "path": "cli/restart.mdx", + "sourceSha256": "0001cc039c216e29704bc8dd032843f33eeda479e3b936864c55ebb82c19392b", + "translationSha256": "5253bcdfe87035d0c94d1a31ce88cb1f95c7c09c2ee5ab6d52f708ea1e9aba41", + "status": "published" + }, + { + "path": "cli/run.mdx", + "sourceSha256": "3edbc8067d4e4223e7f8fabab0d031173b096b641134895988c9693bdc10b5d6", + "translationSha256": "1ed8bb0492388c6627bc7f506e47ef9d43b73a89e2a06bdc8b68ef871ea6966b", + "status": "published" + }, + { + "path": "cli/scale.mdx", + "sourceSha256": "d0128acc8893d2b40bc7b663fe48867ed247851cddc52817ef2f1a55a97bef5e", + "translationSha256": "a71a7b7b132ee742da0bc0679e51ebee9a77323c92fad4388b7843b076635333", + "status": "published" + }, + { + "path": "cli/secrets.mdx", + "sourceSha256": "635491af6079e6a4f8c718f5443f5b19b9b3e8697957a2917a451631eecf3282", + "translationSha256": "8ababfa244db9d621ff44a7d3ff8635d06118f94609d6bb7276eaf61f6dab210", + "status": "published" + }, + { + "path": "cli/service.mdx", + "sourceSha256": "f4a4dedae24ae7928cc0e8279525f80551f1bb01b209beb97254b5966d8ff038", + "translationSha256": "a477086c6e972d4142c1689cf2d56db5c4da353f2fbc7b7cf8ef232aa509dd12", + "status": "published" + }, + { + "path": "cli/skills.mdx", + "sourceSha256": "5ee058f81c64343d5667de9ebd49f1bc975010a25258a74ce92458d638b7731b", + "translationSha256": "f3e1d5370f28a4f25f7a987f56f29aba0c75a9d4279fe37e4b9b7136c8c478a8", + "status": "published" + }, + { + "path": "cli/ssh.mdx", + "sourceSha256": "f2c1105cca6be5eff87de0249a23d52dd4b5302065b6a0839ba3106669664e46", + "translationSha256": "431fbc90ba310d960a902cad260a20007d9f194e1954900b6a2a80bc04a77b98", + "status": "published" + }, + { + "path": "cli/status.mdx", + "sourceSha256": "d1c2b6873e7679bdb11253c71aa03566f64c9d46f30a9de283ac58b42a47af8a", + "translationSha256": "4828ede79dd4fb8f118ccbdf717937e65880f1a512b44659458119b34431197a", + "status": "published" + }, + { + "path": "cli/unlink.mdx", + "sourceSha256": "e824c1f057db0696eee4b37488cdd43292dbe9d08770112d3e9af9b9ab70a5d6", + "translationSha256": "831e7ef066f463de6f0c53be1fca95cae755c302bf5edb9ece7bd5b23ec04f41", + "status": "published" + }, + { + "path": "cli/up.mdx", + "sourceSha256": "8d7512c5e26dbf5a0316437f99e1cc93ce0ebdfe7bf69491636ed767eda36695", + "translationSha256": "cfca086cb63d05bc8ed6495c69d63df4dd2d626abc8d22abb004512903b1227a", + "status": "published" + }, + { + "path": "cli/upgrade.mdx", + "sourceSha256": "1f33d0a46185278e2858d89f7a19e9e57a63d5dd6bd36c66c0f4f348384c8e93", + "translationSha256": "8b3206a6e215d4fa43b50e5d393df716b94b9775f6887f836f9bca438e622b05", + "status": "published" + }, + { + "path": "cli/whoami.mdx", + "sourceSha256": "053bc71c8bd276882bdd10cd64d42ce8e13e500c01424fcfd8e1fd7083b3467d", + "translationSha256": "e6f7b1e6ddfde5ae2c0309c1392611d2c6a73f1fe8e44cbe31181f1460d2dd9e", + "status": "published" + }, + { + "path": "cli/workspace.mdx", + "sourceSha256": "bc138c7663e0b4c8ae76c3b2d55c9f72d83fa08fc19f3475d5e7bc08e7da78d2", + "translationSha256": "c690cc3e90f09984d9742ce4d822398e88973b5b97d886731b203024c073ed2a", + "status": "published" + }, + { + "path": "concepts/architecture.mdx", + "sourceSha256": "fa5a5aa8a4f23b1d89be99fd3d8db0a9f19831991f9d5fb55730fd12dd399cff", + "translationSha256": "cac523af4ce626bcb998d28dcb616f09ff8daf8d4477382aca10f289032db23e", + "status": "published" + }, + { + "path": "concepts/build-pipeline.mdx", + "sourceSha256": "b0ec0991712b3f5ef246a1ec3dea10687a7c592debecec517b6498db2daa4bb3", + "translationSha256": "2f97e1ee66e4b1d6083d3bd5340de4b5275615ff4f044b4471225275ec652ea1", + "status": "published" + }, + { + "path": "concepts/deployments.mdx", + "sourceSha256": "0f54a580f17b7c807cadebe8b0d6ef9bfd793e8b16486c51c6cffb40a8eb8bba", + "translationSha256": "d8e786150a85e3f829f56b93621b2f1628c1f9f96329fb0724ee7b63a13c3f34", + "status": "published" + }, + { + "path": "concepts/index.mdx", + "sourceSha256": "92ffb749631fb660c542e40ff875f7cd8aa4849c9d77d06f4ac286578ee58bc4", + "translationSha256": "c6ed838f640260063678e3ad760a3df0a6efd6981b0718c43e7f6c19a3b33bfe", + "status": "published" + }, + { + "path": "dashboard.mdx", + "sourceSha256": "4fa1240afec8962e3df1c9e564280c83963761f2f64b47502eb8b0d9e9d2ed0c", + "translationSha256": "0567d035ce14ebe5090df71525a3da16f563c8c4e871a97fdde548df0aadc490", + "status": "published" + }, + { + "path": "deploy/github.mdx", + "sourceSha256": "697a33210ef14bb34a5074f44847fa69cb7ea169494942fc571e773b200b44c2", + "translationSha256": "b9aeba31079cd54dbb1781e6445327a320876afa1713ca8b5d8494b8e86b7903", + "status": "published" + }, + { + "path": "deploy/index.mdx", + "sourceSha256": "39a4a222ec6cbf55b0d98393646ad7690433e651cc81e3954e85a713157c193f", + "translationSha256": "677aac78d7e6fd5b72167e013a3724a602188e91e1df8cd03f496c05df4b65c6", + "status": "published" + }, + { + "path": "deploy/regions.mdx", + "sourceSha256": "83fc01f4cafa29b368b5bee232de3db69a7fa0c92fd74a6a16381c327005881e", + "translationSha256": "54a219e53ec865491ba7091bfcd2b53ceae59475bd1e21643f8c76b8f726b258", + "status": "published" + }, + { + "path": "deploy/scaling.mdx", + "sourceSha256": "563e23a94dc6dd4c634c141f4e953dfc97fcc9a2002cf54ba1030e36e3d83748", + "translationSha256": "890275e97e0f248b888ba0d274acb76e885e1fa6c2656ca3275bcb0d5cf159b7", + "status": "published" + }, + { + "path": "deploy/troubleshooting/double-build.mdx", + "sourceSha256": "1d2254daad7f87e1fbe9e869bd6e0a2f7afbb71ef73e9964e2d2be3b7c011884", + "translationSha256": "7385e7f2bf3f1b871a95820c07d4bdc3e621f581b8daaa41b548eaff235048e0", + "status": "published" + }, + { + "path": "deploy/troubleshooting/incomplete-dockerfile.mdx", + "sourceSha256": "6f9a46f14284e8c095ef4450973b21b6841073c0b8a959e233e267ff437cc6e0", + "translationSha256": "f96f1a14d9c29f96c7fc51bc1ff61733e1c8c9f0eab0bd2218671eb905ff476d", + "status": "published" + }, + { + "path": "deploy/troubleshooting/service-never-healthy.mdx", + "sourceSha256": "9d348e4d46599ed785b0c8d7d906d3672c8ad834114a3d80834467af954e17a8", + "translationSha256": "7d18a184c6e923dfe2a06e076e0749ca7b2a6ccb42a13f1da6ef6a230f462ce6", + "status": "published" + }, + { + "path": "deploy/upload.mdx", + "sourceSha256": "17fc2068ae350b3a6ab7349e29fc908abb1ca8087260c7ed8e0025ec5a053941", + "translationSha256": "fb9fcb2519c82d43182a3db09d6997b61eb35bf5bb36ce59084f25b21b427fae", + "status": "published" + }, + { + "path": "deploy/workers.mdx", + "sourceSha256": "43a2bbbb43fb079d035d5cf785f7e6c0536f84ed941e54bc8382a067df0b6fad", + "translationSha256": "a315b979c47a435bf4c109fbf6a8ba63845083dfa10bd2f349697e996e44d188", + "status": "published" + }, + { + "path": "framework-guides/astro.mdx", + "sourceSha256": "4b89ac3379be48f204f3b932680f0900161e7373ed2436590be3456dd07e6315", + "translationSha256": "25bbde6c158a6bde46042e0edaadf5ec8db06b97c1a9628162bd095c0c39e1f0", + "status": "published" + }, + { + "path": "framework-guides/django.mdx", + "sourceSha256": "11422a3685e71d7b95f2055799ca16c9037ebe8a279c1d9c1c891a2dade79440", + "translationSha256": "b6cc8bf55f48d909f26d1b19ed41f6988cf6f3cde4af97a247414f68b2277371", + "status": "published" + }, + { + "path": "framework-guides/docusaurus.mdx", + "sourceSha256": "65a0cbde6b2ba696cfb9cc99b45a0c4f7d7d82b24763d82230ede29eb48fe20f", + "translationSha256": "19c3ffce9a34085f44ed0381b17044ea7d370933fa9123fd3b4fde21ab567a4c", + "status": "published" + }, + { + "path": "framework-guides/fastapi.mdx", + "sourceSha256": "9da90747b275c5d3b46aa6827ff7603ec6efb1cc4fffe48836c58d4770f904f8", + "translationSha256": "54db3d16d0c9cecac5f3c109ed2e143b2e37eda1f56ab449e97d5f98656ff119", + "status": "published" + }, + { + "path": "framework-guides/hugo.mdx", + "sourceSha256": "c552b74cc22994ab2e17d5a0c1eb4afdaf2d00f64960d9581bcf46300f6c202c", + "translationSha256": "f33dd063b74144bc5dfcd968875f76077cd5f46e688ed252d7a691d5b65a0c8a", + "status": "published" + }, + { + "path": "framework-guides/index.mdx", + "sourceSha256": "ca924027746d3390d618495318c3fdde147d705193b3e04d30d71ac779c2a33a", + "translationSha256": "d21810ac549d8720aa7fa8ccee563572efd551d7ea15f74f322e05b2b9c426ad", + "status": "published" + }, + { + "path": "framework-guides/nextjs/index.mdx", + "sourceSha256": "a30666d082660a9a10e0f8a990b0ac1a476ad16d71c45c3e33d11e8d7f9ed926", + "translationSha256": "5cf7768155459cc6bc50e8c0e47e7b501c5d0b97651f5fc51cc49d96cb8f8fa1", + "status": "published" + }, + { + "path": "framework-guides/nextjs/static-export.mdx", + "sourceSha256": "344b7b0a3c925f9e5f7df53054d3aa1525dd8e0b2c98c2e86fd990fa8309a795", + "translationSha256": "d4755bf7b5a4a76383f90ab80a9901fcec1a55eb5bb4977c054ec42f5a74bc27", + "status": "published" + }, + { + "path": "framework-guides/nuxt.mdx", + "sourceSha256": "edfe7100de75c167475248a291fbb276ab899e4e9aba4aabb37745720b4180ee", + "translationSha256": "6cc19799f36ff157d3c4a9f8679e3b5b6a88eb43f45cac2026cbf95c5b64f25f", + "status": "published" + }, + { + "path": "framework-guides/react.mdx", + "sourceSha256": "c96a03f9b274d91751231de136d1a37a2554ebcdad8ebffd5b11067c06537c34", + "translationSha256": "9647a684ced3ab175fcce784c1367d7828ce13744c684e43e25a71ae21368e6c", + "status": "published" + }, + { + "path": "framework-guides/static-routing.mdx", + "sourceSha256": "277dbfc3d581d2ba332fe183807134aca7084876648a0aca7cb4b7cf227caf43", + "translationSha256": "d35173389aef390a9e21e5addc1646f122b2929a4fc383719eba024e9b1d1ec5", + "status": "published" + }, + { + "path": "framework-guides/sveltekit.mdx", + "sourceSha256": "eb98e0ae2bcc536998735b23d6d28ea658fce42e1139c78d3eb4570a54347d52", + "translationSha256": "e8b456be0731d8817b47643fc2591aa075a4bcf05d205762f69c2418d57f2d5e", + "status": "published" + }, + { + "path": "framework-guides/validation.mdx", + "sourceSha256": "068375b554451b4be0aa21b2ea7d53789e61e44cd592947877cce6223240f26f", + "translationSha256": "6fb0a3ae4c3178cee3e35607fc341d208ec9bc819a3d5d6a1faadc9eae7fb534", + "status": "published" + }, + { + "path": "framework-guides/vitepress.mdx", + "sourceSha256": "5e3d98d5d3e2dcbb5af644fb500e39389e216efe772eda2933aa291384aebda4", + "translationSha256": "7331760e19e99ea79e5ec5e78681cbaf8de0163507b4ab1362a0c98d87f45efd", + "status": "published" + }, + { + "path": "framework-guides/vue.mdx", + "sourceSha256": "442bd3f20789c9c6243ed364d8e4c350efebeb33a289334ee5222c9047217098", + "translationSha256": "f8134f3f8e9e64316201028838cf777e44a5ece7f315b0b31f6d9b22474c385d", + "status": "published" + }, + { + "path": "getting-started.mdx", + "sourceSha256": "34aa52cecefcc9a9ef34f3eb6586c8cd42de7cad388916e983aabc31c77a1527", + "translationSha256": "2afcb6ddb11b19c362701acefbed31ed9281520493f1433334be6ad407694d8f", + "status": "published" + }, + { + "path": "guides/deploy-from-coding-agent.mdx", + "sourceSha256": "446afe16553138fce16e5ee5aba6c52f600eb9d7f3b326f8822eabbec56ea734", + "translationSha256": "cb3c4c07f22e9ecb6d25526402347ef4ffbcf3cbc02b61c9bf2d2cd831ef783b", + "status": "published" + }, + { + "path": "guides/deploy-mcp-server.mdx", + "sourceSha256": "55f7aea7cf3929bb84cd7ad4b67c1feb52cc707d888ec00fa2a7fe702d417738", + "translationSha256": "6e218e620e9833245927be40896a0cd51700ac81a095128147db8369ca44dc5c", + "status": "published" + }, + { + "path": "guides/flowise.mdx", + "sourceSha256": "fa697aec8657e3ea920d1c88a6095ff442064a0ab3c0a812f10e5e5c5c1ee1b6", + "translationSha256": "172243b79293465151ad06a54b5e8abe3b0798e74de85742eb8992ec4d87bbfb", + "status": "published" + }, + { + "path": "guides/index.mdx", + "sourceSha256": "6492dcbd87273f0bc2148b1b3cf3e787ce4873932c2b270d11685f8984615ac6", + "translationSha256": "27ae46fbea4503524034ed833413ca4d1839feef38d6de44182cd2815c86228a", + "status": "published" + }, + { + "path": "guides/telegram-bot.mdx", + "sourceSha256": "db7b0a93dbae68b767e93022e99d2684dc7f8881bb4060cc2743c2f95742510a", + "translationSha256": "54dc073841bf8cc1cd07e48f4c1e6cf70ca84cf8706584562914504ec3480487", + "status": "published" + }, + { + "path": "guides/umami.mdx", + "sourceSha256": "60ac58aa3f74b7b22f7a29c2dabb1040983ffb9635ec0364bea5f4eeb9a1a184", + "translationSha256": "bc03d45bfb5c869c3d4fe30a64d6698d6d8d59ff06466718e776291b71066af2", + "status": "published" + }, + { + "path": "guides/validation.mdx", + "sourceSha256": "f060ee682789b323ce18e0f282ba6bb47a85accc912583a7600e69546dd9aeed", + "translationSha256": "e54dfcdcf09dd0929193a611b0643168660b2b4cf57d85bb0518719f0bd3d720", + "status": "published" + }, + { + "path": "index.mdx", + "sourceSha256": "45b40d974470539641750f9473f39a6af74fbf999f39e8fb924c867abcc18370", + "translationSha256": "244e34365013b38c9cdb8ba49410cb58ac1b4cb90bcadd06a1d740db7f129de7", + "status": "published" + }, + { + "path": "networking.mdx", + "sourceSha256": "cf23c1a1df8c7e4b7835590d38786dc0574de771374c42dea5c1f5fdfc0079fd", + "translationSha256": "489a9c8290cd1de5026a7ab781d354abde0c72a0ec604981a2efba3e22f0860e", + "status": "published" + }, + { + "path": "observability/events.mdx", + "sourceSha256": "db2092362e0139e9ef1b6816eafd3f90ecfca59faad01fe1dfe0383057ce6bdb", + "translationSha256": "75ff19362d501172fcb3d097a6ab240109c7a600bd9d8f04e6cabf860ecf004c", + "status": "published" + }, + { + "path": "observability/index.mdx", + "sourceSha256": "c99b35a322a98276ae9759c2443b7e1ebb77bb2a07b15391d6eff2d4e0d59fd1", + "translationSha256": "028b9b48cbdd7eb2bdaba472179af74215c3abfd162dc10ed213746e7eec5dbf", + "status": "published" + }, + { + "path": "observability/logs.mdx", + "sourceSha256": "9e1e57fcde78990342ebd7619a1d5762f15dfb35c95142885f8c561bb9e35d40", + "translationSha256": "1426eddbfd2896bc4f03add77e2bdbd95af8faf2fbbea94a0e0b4035c981c3fd", + "status": "published" + }, + { + "path": "observability/metrics.mdx", + "sourceSha256": "f95728b789c693cc7de9e37c2e8b07e8e35a8129fa754ac7aa8c296b97a7364a", + "translationSha256": "99b6b414f13789494843ac8f8a591c17cf0a93747c4d709c62a0cec551b0c8da", + "status": "published" + }, + { + "path": "platform/billing.mdx", + "sourceSha256": "a93fe73b92ee9d775f4b3e8182db6b719f6a1e8fa988b9f0a482eb5e24d29c62", + "translationSha256": "e45fd7293269e11140d21cf77cdaf025d4176865680015abf45cb92108b72fd1", + "status": "published" + }, + { + "path": "platform/known-issues.mdx", + "sourceSha256": "d9d69003cc9345a6059440d9f03894ceb437d7173be215e95403ba9b9210aec0", + "translationSha256": "9438dc5cbdebc4c5f0f6bde142843ad0965c649c8df946531969ac451f276656", + "status": "published" + }, + { + "path": "platform/limits.mdx", + "sourceSha256": "5f2166c38b61c6dc032b4f0e4ac1fc1ae2c8a14db9af49ffd2371a7bf4649214", + "translationSha256": "c7f7ce1fa0d47de58173ba768747f4fce5f28336c6ccceaa178bf40b5ee6b4c9", + "status": "published" + }, + { + "path": "platform/storage-and-recovery.mdx", + "sourceSha256": "30a114b2f76b0d2bbcf67cdd2a07630ef1c3992a526aa8915ca30a63d0ba18d4", + "translationSha256": "866fd492d7b597ae2e33c5731b9ce17f213a1fa10097bbbed39d34774f277fca", + "status": "published" + }, + { + "path": "sandboxes/code-interpreter.mdx", + "sourceSha256": "d187221290fdbba78567a330e562a618cdd7d9fff31cc32c74b7ed9c1c67f241", + "translationSha256": "853318e1bb2af621418e48ab657f6165c599461ea2b5465c2c9aded24a9cc388", + "status": "published" + }, + { + "path": "sandboxes/dashboard.mdx", + "sourceSha256": "828415eb0c46fce33f20bc2dae780262eacabf58127a590b1d681d54966db527", + "translationSha256": "b5df3e9f4bd4b77af98f78570765c795e6283a700e8c063de163852afd439086", + "status": "published" + }, + { + "path": "sandboxes/index.mdx", + "sourceSha256": "f07dd490dcb4e1b5376d256de65e13d79a37688fb8286b2dd6578e0eb14fdfbb", + "translationSha256": "688ef78c7c77de42f643a3ebd21033b34ceb844a60aa285f240fe8fcca05a2b8", + "status": "published" + }, + { + "path": "sandboxes/quickstart.mdx", + "sourceSha256": "c58f024fe163b5142bf554232363ffd74fce365d54cebc2f14ae997f9ab210dd", + "translationSha256": "dc0efbc0bcdfc47142babdbaacb4c4a751b968d939e4b0a2f0ac6242617bed31", + "status": "published" + }, + { + "path": "sandboxes/sdk-reference.mdx", + "sourceSha256": "2ef3c1a78d607f5daec121d792e10e66b25dc62538da865aaed3cc69a1947bd9", + "translationSha256": "a18f882f718b5791cb7293be9ac13a4cbe9f9217fb788ae91bb038565eff94ba", + "status": "published" + }, + { + "path": "sandboxes/volumes.mdx", + "sourceSha256": "335158c3113ae1afa8cf0c966ffb5390d4e52b4e21965058318be124b5235438", + "translationSha256": "b3948ba79e135208246475798b5b22a3bc035efa88046894eb5425948598147c", + "status": "published" + }, + { + "path": "studio/getting-started.mdx", + "sourceSha256": "3d6df5a941a22427bf6146f91cf795ceac7439aaf86d8c2d1213dcd3ba8ba2ae", + "translationSha256": "7ab99c63104ccc7fb675c26fb6e281b39ff4d16f7ea666b9d3308c7b43a0c9e5", + "status": "published" + }, + { + "path": "variables/index.mdx", + "sourceSha256": "2b605e838fc7dc268894a433dd4dfea5f3aa9b786ee80b334f9ae9edb242400c", + "translationSha256": "255950908646549558fe9ed7035084a05dca46bb8bad6c5bc926b7dfd771e4f2", + "status": "published" + }, + { + "path": "variables/references.mdx", + "sourceSha256": "21300a1c62e7d69d9bd9c935f95985ad1dc03fd5085ab6b862749b178f34f89c", + "translationSha256": "af5b08e153b37640f05ddbae07163ae6c648c62054ff8a005d162570c577d294", + "status": "published" + }, + { + "path": "variables/troubleshooting/reference-not-applied.mdx", + "sourceSha256": "2be66a188aa38cb545bd36437c19d928f70eedab58c3b38a7a2ae7720c5f25fa", + "translationSha256": "1a630a7e6a80734eb540557fc287f75d220ea4ba618a8b6e739841fcd36a1085", + "status": "published" + } + ] +} diff --git a/_locales/ja/networking.mdx b/_locales/ja/networking.mdx new file mode 100644 index 0000000..2f32d39 --- /dev/null +++ b/_locales/ja/networking.mdx @@ -0,0 +1,85 @@ +--- +description: "すべてのサービスには、自動 TLS 付きの onlizard.com ドメインが付与されます。カスタムホスト名を追加し、DNS を検証し、ポートを公開し、またはドメインを削除できます。" +--- + + + +# ネットワーキング + +すべてのサービスは、リージョンに関係なく、デプロイされた瞬間に自動 TLS 付きの生成済み `*.onlizard.com` ドメインを取得します。本番公開の準備ができたら、独自のホスト名を追加してください。 + + + +## 生成されるドメイン + +サービスのデフォルトドメインは自動的に作成されます。表示するには（または新しく生成するには）: + +```bash +lizard domain # show the service's current domain +lizard domain generate # generate a new *.onlizard.com subdomain +``` + +[S3 addon](/addons/storage) から提供される Object Storage は、代わりにリージョンスコープのゲートウェイホスト（`s3-.onlizard.com`）を使用します。 + + + +## カスタムドメインを追加する + +ホスト名は**位置引数**です。`add` サブコマンドはありません: + +```bash +lizard domain app.example.com --service web +``` + +Lizard は、作成すべき DNS レコード（ホスト名用の `CNAME` と、検証用の `TXT` レコード）を返します。これらを DNS プロバイダーで追加してください。 + + + +## 検証 + +DNS の伝播が完了したら、ドメインを有効化します: + +```bash +lizard domain verify app.example.com +``` + +これにより `TXT` レコードが確認され、ドメインが有効化されます。TLS は自動的にプロビジョニングされます。 + + + +## ドメインを削除する + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes # alias, skip confirmation +``` + + + +## 特定のポートを公開する + +サービスがデフォルト以外のポートで提供される場合は、そのポートにドメインを追加します: + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +## Worker サービス + +[workerモードのサービス](/deploy/workers)（`containerPort=0`）では、生成されたドメインが表示されることがありますが、何も提供されません。リスナーもロードバランサーのルートもないためです。worker にカスタムドメインを追加しないでください。 + + + +## ダッシュボードで管理する + +ダッシュボード（`lizard open`）の **ドメイン** ビューでは、各ドメインの検証状態と TLS 状態を確認でき、ホスト名の追加や削除も視覚的に行えます。 + + + +## 関連項目 + +- [`lizard domain`](/cli/domain) — 完全なコマンドリファレンス。 +- [リージョン](/deploy/regions) — レイテンシのためにサービスと addon を同じ場所に配置する方法。 +- [プロトタイプから、人々がお金を払う SaaS へ](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#from-vibe-coded-prototype-to-a-saas-people-pay-for) — 生成されたアプリにまだ必要な他の要素の中で、カスタムドメインがどこに位置づけられるか。 diff --git a/_locales/ja/observability/_meta.ts b/_locales/ja/observability/_meta.ts new file mode 100644 index 0000000..0df95e6 --- /dev/null +++ b/_locales/ja/observability/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "概要", + logs: "ログ", + metrics: "メトリクスとコスト", + events: "イベントと履歴", +}; diff --git a/_locales/ja/observability/events.mdx b/_locales/ja/observability/events.mdx new file mode 100644 index 0000000..ada2156 --- /dev/null +++ b/_locales/ja/observability/events.mdx @@ -0,0 +1,45 @@ +--- +description: "lizard events でサービスのデプロイタイムラインと稼働中レプリカのライブステータスを確認し、ダッシュボードの デプロイメント ビューでも同じ履歴を見つけます。" +--- + +# Events & History + +`lizard events` は、サービスのデプロイ履歴とレプリカのライブステータス、つまりデプロイされた内容と現在実行中のもののタイムラインを表示します。 + + + +## イベントを表示する + +```bash +lizard events # deploy history + replica status +lizard events --service api # a specific service +lizard events --limit 25 # show more entries (default 10) +``` + +各エントリは、デプロイまたはスケーリング操作と、その結果のレプリカ状態を扱うため、"何が変わったのか、そして正常か？" をひと目で確認できます。 + + + +## クイックステータス + +プロジェクト内のすべてのサービスのスナップショットをすばやく確認するには — ステータスと URL を含めて — 次を使用します: + +```bash +lizard ps +lizard status # the current directory's workspace/project/service link +``` + + + +## ダッシュボード + +ダッシュボードの **デプロイメント** ビュー（`lizard open`）は、同じ履歴をタイムラインとして表示し、デプロイごとの詳細ドロワー（ビルドログ、コミット、ステータス）とレプリカごとのヘルスを確認できます。 + + + +## 関連項目 + +- [デプロイメント](/concepts/deployments) — デプロイのライフサイクル。 +- [ログ](/observability/logs) — ランタイム、ビルド、再起動のログ。 +- [Metrics & Cost](/observability/metrics) — リソース使用量と請求。 +- [`lizard events`](/cli/events) — 完全なコマンドリファレンス。 diff --git a/_locales/ja/observability/index.mdx b/_locales/ja/observability/index.mdx new file mode 100644 index 0000000..a0a1ce7 --- /dev/null +++ b/_locales/ja/observability/index.mdx @@ -0,0 +1,19 @@ +--- +description: "サービスの動作を確認: ログをストリーミングし、メトリクスとコストを追跡し、デプロイとレプリカの履歴を確認します。" +--- + + + +# 可観測性 + +サービスの動作を確認: ログをストリーミングし、メトリクスとコストを追跡し、デプロイとレプリカの履歴を確認します。 + + + +## このセクションの内容 + +- [ログ](/observability/logs) — ビルドログと再起動ログを含む、ライブおよび過去のログ。 +- [メトリクスとコスト](/observability/metrics) — リソース使用量とそのコスト。 +- [イベントと履歴](/observability/events) — デプロイのタイムラインとレプリカごとのステータス。 + +ここにある各ビューには `--json` フォームもあり、これはデプロイが正常に動作しないときに AI コーディングエージェントが読み取るものです — [Claude Code からのデプロイ](https://lizard.build/blog/deploy-from-claude-code) を参照してください。 diff --git a/_locales/ja/observability/logs.mdx b/_locales/ja/observability/logs.mdx new file mode 100644 index 0000000..fc26e5c --- /dev/null +++ b/_locales/ja/observability/logs.mdx @@ -0,0 +1,73 @@ +--- +description: "CLI またはダッシュボードから、ランタイムログをストリーミングし、デプロイ失敗後にビルドログを確認し、再起動前後のログ末尾を取得します。" +--- + + + +# ログ + +Lizard は、**ランタイム**ログ、**ビルド**ログ、そして**再起動**前後のログ末尾を収集します。ターミナルでライブストリーミングすることも、ダッシュボードで閲覧することもできます。 + + + +## ランタイムログ + +```bash +lizard logs # last 200 runtime lines, then live tail +lizard logs --service api # a specific service +lizard logs --tail 1000 # more history (max 1000) +lizard logs --level error # filter by level +``` + + + +### `--json` を使った場合の動作 + +`lizard logs --json` は**ストリームではありません**。直近 200 行を返し（`--tail N` で上書き可能、最大 1000）、終了します。スナップショットやスクリプトで使用してください。ライブストリーミングは、対話的に末尾を追いたいときに限り、`--json` を付けずに使用してください。 + + + +## ビルドログ + +```bash +lizard logs --build # the most recent build's logs +``` + +デプロイが失敗したときは、まず最初にここを確認してください。内容を読み、原因を修正してから、`lizard redeploy` を実行します。[ビルド Pipeline](/concepts/build-pipeline) を参照してください。 + + + +## 再起動 / クラッシュログ + +レプリカがクラッシュまたは再起動した場合は、その前後のログ末尾を取得します。 + +```bash +lizard logs --restart latest # the most recent restart +lizard logs --restart # a specific restart +lizard logs --restarts # list recent restarts +``` + + + +## 履歴をページングしてたどる + +`lizard service logs` は、さらに古い期間をページングして取得できます。 + +```bash +lizard service logs --service api --tail all # full history (no follow) +lizard service logs --service api --page 2 # older window (implies --tail 200) +``` + + + +## ダッシュボード + +ダッシュボード（`lizard open`）では、検索とレベルフィルター付きでランタイムログとビルドログをストリーミングでき、**デプロイメント** ビューではデプロイごとのビルド出力を表示します。 + + + +## 関連項目 + +- [`lizard logs`](/cli/logs) — 完全なコマンドリファレンス。 +- [Events & History](/observability/events) — デプロイ履歴とレプリカのステータス。 +- [Claude Codeからデプロイする](https://lizard.build/blog/deploy-from-claude-code) — あなただけでなく、エージェントにも読まれることを想定して書かれたログ。 diff --git a/_locales/ja/observability/metrics.mdx b/_locales/ja/observability/metrics.mdx new file mode 100644 index 0000000..fbe5ea3 --- /dev/null +++ b/_locales/ja/observability/metrics.mdx @@ -0,0 +1,50 @@ +--- +description: "サービスの CPU、メモリ、ネットワーク、ディスクを追跡し、現在のスケールのコストを確認して、表示された数値に基づいて対応します。" +--- + + + +# メトリクスとコスト + +CLI またはダッシュボードから、サービスの CPU、メモリ、ネットワーク、ディスクを追跡し、何にいくらかかっているかを確認できます。 + + + +## メトリクスを表示 + +```bash +lizard metrics # CPU / memory / network / disk +lizard metrics --service api # a specific service +lizard metrics --range # time window +lizard metrics --watch # live-updating view +``` + + + +## コストを含める + +```bash +lizard metrics --cost +``` + +リソース使用量とあわせてコストの数値を追加し、現在のスケールの料金を確認できるようにします。 + + + +## ダッシュボード + +ダッシュボード（`lizard open`）では、これらが **Metrics / オブザーバビリティ** ビューにチャートとして表示され、**使用量** ビューではプロジェクト全体の使用量と請求の内訳を確認できます。次のコマンドで開きます: + +```bash +lizard open +``` + + + +## 表示内容に基づいて対応する + +- CPU/メモリ使用率が高い → スケールアップ: `lizard scale --service api --cpu 2 --memory 2048`. +- 負荷が継続している → レプリカを追加: `lizard scale --service api --replicas 3`. +- アドオンのディスク逼迫 → ストレージを拡張: `lizard scale --service postgres --storage 8192`. + +[スケーリング](/deploy/scaling) を参照してください。 diff --git a/_locales/ja/platform/_meta.ts b/_locales/ja/platform/_meta.ts new file mode 100644 index 0000000..b0ca836 --- /dev/null +++ b/_locales/ja/platform/_meta.ts @@ -0,0 +1 @@ +export default { billing: "請求とクレジット", limits: "制限", 'storage-and-recovery': "ストレージと復旧", 'known-issues': "既知の問題" }; diff --git a/_locales/ja/platform/billing.mdx b/_locales/ja/platform/billing.mdx new file mode 100644 index 0000000..398d67e --- /dev/null +++ b/_locales/ja/platform/billing.mdx @@ -0,0 +1,63 @@ +--- +description: "Lizard の pay as you go: リソース料金、アカウントクレジット、任意の自動チャージ、支払い手数料、残高がなくなった場合の動作。" +--- + + + +# 従量課金 + +Lizard には、標準アカウント向けの月額サブスクリプションやシート料金はありません。アカウントにクレジットを追加し、使用したリソースに対して支払います。未使用の購入済みクレジットは残高に保持されるため、利用の少ない月でも別のパッケージを購入する必要はありません。 + + + +## リソース料金 + +価格は米ドルです。 + +| リソース | レート | +| --- | ---: | +| CPU | vCPU秒あたり $0.000006948 | +| Memory | GB秒あたり $0.000003474 | +| Persistent Volumes | GB秒あたり $0.000000054 | +| Managed Object Storage | GB月あたり $0.0135 | +| Outgoing traffic | GBあたり $0.045、最初の1バイトから | + +受信トラフィックには料金がかかりません。Apps、Managed Postgres、Managed Redis、Sandboxes には、同じ該当リソース料金が適用されます。アカウントのリソース上限は引き続き適用されます。クレジットを追加しても、それらの上限は増えません。 + +たとえば、1 vCPU と 1 GB のメモリを 1 時間使用した場合、コンピュート料金は $0.0375192 です。ストレージ、送信トラフィック、支払い手数料により、この金額に加算される場合があります。これはリソースコストの例であり、チャージ時に請求される金額ではありません。 + +提供内容の全体については、[現在の料金](https://lizard.build/pricing)を参照してください。Enterprise の請求は契約に従います。 + + + +## アカウント残高 + +ワークスペースでの使用量は、その所有者のアカウント残高から差し引かれます。メンバーを追加してもシート料金はかかりません。Credits ページには、残高、購入履歴、期限切れになるクレジットが表示されます。 + +- **購入済みクレジットに有効期限はありません。** 毎月リセットされることもありません。 +- **トライアルクレジットには有効期限があります。** 新しいアカウントには $10 のトライアルクレジットが付与され、有効期間は 31 日間です。 +- **プロモクレジットには有効期限がある場合があります。** 付与分に表示される条件と有効期限を確認してください。 + +購入済み残高は利用料金の支払いに充てられます。リソース料金に対する割引ではありません。他のプロバイダーとコストを比較する際に、これを再度差し引かないでください。 + + + +## チャージと手数料 + +資金を追加するには、アカウント設定の **Credits** を開きます。確定前に、チャージ画面には最小金額、クレジット額、支払い手数料、合計請求額が表示されます。最小チャージ額は月額料金ではありません。 + +自動チャージは任意です。Credits 設定で、残高しきい値と金額を選択します。そこで無効にすることもできます。自動チャージを無効にしても、リソースが停止したり、その利用料金の請求が終了したりすることはありません。 + + + +## 残高不足または残高ゼロ + +Lizard は残高が少なくなると警告します。残高がなくなり、支払いによって復旧されない場合、リソースの作成が制限されることがあり、実行中のサービスは適用される猶予期間後に一時停止することがあります。アカウント条件は Credits ページで確認し、一時停止を避けるため、猶予期間が終了する前に残高を復旧してください。 + + + +## アイドル状態のアプリと保存データ + +アプリは、リクエストがない場合でもメモリと CPU を使用することがあります。コンピュート使用量を止めるには、アプリを停止してください。Persistent Volumes と Managed Object Storage は、アプリが停止している場合も含め、データを保持している間はストレージ料金が発生し続けます。 + +データを削除する前に、[ストレージと復旧](/platform/storage-and-recovery)を確認してください。設定済み上限と実測使用量を比較するには、[metrics](/observability/metrics)を参照してください。 diff --git a/_locales/ja/platform/known-issues.mdx b/_locales/ja/platform/known-issues.mdx new file mode 100644 index 0000000..cdf2a28 --- /dev/null +++ b/_locales/ja/platform/known-issues.mdx @@ -0,0 +1,51 @@ +--- +description: "ワークフローに依存する前に確認すべき、現在の Sandboxes のライフサイクル上の注意点、デプロイ復旧の制限、ビルド設定の優先順位。" +--- + + + +# 既知の問題 + +このページでは、注意が必要な挙動や、リリースによる確認が必要な挙動を記録しています。レビュー中のコード修正は、稼働中のサービスについての保証ではありません。 + + + +## サンドボックス の一時停止と有効期限 + +一時停止は、残りの有効期間を凍結することを意図しています。ノードの時計と別のクリーンアップ処理の競合により、一時停止された sandbox が元の期限後に終了することがあります。有効期限のない sandbox の node-agent 再起動と再開についても、ライフサイクル修正が必要です。 + +その修正が実環境テストを通過し、お使いのリージョンに届くまでは、長期的な状態保持を一時停止だけに頼らないでください。ファイルは `/data` 配下の Persistent Volumes に保存するか、アプリケーションの状態をデータベースまたはオブジェクトストレージに保存してください。ホストメモリはバックアップではありません。明示的な有効期間を設定し、タスク終了時には sandbox を解放してください。 + + + +## 再デプロイはロールバックではありません + +`lizard redeploy` は、選択したソースを現在の構成でもう一度ビルドします。以前のビルドを選択するわけではありません。ビルド失敗と起動失敗では影響が異なります。復旧手順を選ぶ前に、アクティブなサービスとそのログを確認してください。起動失敗時でも、すべてのランタイムが古いリリースの提供を維持するとは限りません。 + + + +## Dockerfile の優先順位 + +明示的な build コマンドまたは start コマンドは、リポジトリの Dockerfile より優先されます。`dockerfilePath` を選択する場合は、これらのオーバーライドをクリアしてください。設定更新それ自体がビルドを開始することがあるため、別の再デプロイを送る前にイベントを確認してください。[Dockerfile のトラブルシューティング](/deploy/troubleshooting/incomplete-dockerfile)を参照してください。 + + + +## テンプレートと MCP + +現在の Sandboxes 作成 API は、組み込みの 2 つのテンプレートを受け付けます。カスタムテンプレートに `lizard push` を使う手順は、現在公開されている CLI と一致しません。 + +Lizard Skill は Lizard CLI を使用します。そのワークフローでは MCP トランスポートは公開されません。独自のリモート MCP サーバーをホストするには、別個のアプリケーションデプロイが必要です。[ガイド](/guides/deploy-mcp-server)を参照してください。 + + + +## サービスポートの変更: 2026-09-09 に修正済み・確認済み + +9 月 7 日の確認では、準備完了のプロセスがあるにもかかわらず、アップロードサービスのポートを `3000` から `80` に変更した後に HTTP 503 が発生しました。本番修正により、選択したポートが実行中のサービスに適用され、アップロード時および再ビルド時にも明示的なポートが維持されるようになりました。実環境でのポート変更確認は 9 月 9 日に成功しました。デプロイ後は、サービス状態だけでなく公開 URL も確認してください。 + + + +## アップロードアーカイブとビルド失敗時の終了コード: 修正済み + +Lizard CLI 0.3.95 は、ソースアップロードから macOS の `._*` メタデータエントリを除外し、クラウドビルド失敗時に非ゼロの終了コードを返します。古い CLI バージョンは更新してください。`COPYFILE_DISABLE` はもう不要です。[フレームワークチェック](/framework-guides/validation)では、現在の CLI を使った macOS からのアップロードをカバーしています。 + +ビルドの成功だけでは、アプリが動作する証明にはなりません。デプロイ後に公開 URL、ルート、フォーム、データ操作を確認してください。 diff --git a/_locales/ja/platform/limits.mdx b/_locales/ja/platform/limits.mdx new file mode 100644 index 0000000..fecdff3 --- /dev/null +++ b/_locales/ja/platform/limits.mdx @@ -0,0 +1,49 @@ +--- +description: "デプロイ前に、アプリのレプリカ上限、Sandboxes のリソースとタイムアウト、リージョン、アカウントクォータの適用範囲を確認してください。" +--- + + + +# 制限 + +制限は、リソース、プラン、アカウントによって異なります。レプリカごとの設定は、サービスまたはアカウント全体で利用可能な合計ではありません。ワークロードのサイズを決める前に、現在のプランと、作成またはスケールリクエストの結果を確認してください。 + + + +## アプリケーション + +| 設定 | スコープ | 確認すべき項目 | +|---|---|---| +| CPU and memory | 各レプリカ | 上限が 2 vCPU / 2 GiB のレプリカが 3 つある場合、設定上の合計上限は 6 vCPU / 6 GiB です。これは使用量の予測ではありません。 | +| Replica count | サービスとプラン | API は 1–10 を受け付けますが、プランの制限によりこの範囲が狭まることがあります。Standard プランのチェックでは 1、Pro/Enterprise では 5 までで、アカウントごとの上書きが適用される場合があります。 | +| アカウント リソース上限 | アカウント所有者 | 2 つ目のプロジェクトを作成しても、必ずしも 2 つ目のクォータが作成されるわけではありません。大規模なデプロイを計画する前に、実効アカウント上限を確認してください。 | +| Worker mode | サービス | `containerPort=0` は、HTTP リスナーや公開ロードバランサールートなしで実行されます。 | +| Custom domain | ホスト名 | ワイルドカードカスタムドメインは受け付けられません。特定のホスト名を使用し、所有権確認と DNS チェックを完了してください。 | + +アプリケーションでは異なるランタイムを使用できます。すべてのアプリケーションが Sandboxes と同じ Firecracker micro-VM 境界を持つとは限りません。 + +## Sandboxes + +| 設定 | 現在の作成 API | +|---|---| +| CPU and memory | 4 vCPU / 4096 MiB | +| テンプレート | `base`, `code-interpreter-v1` | +| Raw APIデフォルト有効期間 | `timeoutMs: 0`, 有効期限なし | +| Lizard SDKデフォルトライフタイム | 300000 ms、5 分 | +| 明示的なライフタイム範囲 | 0 から 2147483647 までの整数ミリ秒 | +| ライフタイムの更新 | 少なくとも 1000 ms。アイドルタイマーではありません | +| 永続ボリュームのアタッチ | 一度に 1 つの sandbox、ボリュームのノード上 | + +スクリプトからは明示的な lifetime を渡してください。たとえば、`--timeout 300000` を使うと、Lizard CLI のリリースをまたいでも意図した上限が明確になります。セッションを待機状態にする前に、[一時停止と有効期限](/platform/known-issues#sandbox-pause-and-expiration)を参照してください。 + + + +## リージョン + +現在設定されているリージョンには、US East (Virginia)、`us-east-1`、EU West (Limburg)、`eu-west-lim-a` が含まれます。カタログにリージョンがあっても、すべてのリソースで利用可能な容量が保証されるわけではありません。リソース作成時にリージョンの選択肢を確認してください。既存のボリュームを使用する sandbox は、そのボリュームのノード上で実行する必要があります。 + + + +## スケールを増やす前に + +アクティブなプラン、レプリカごとの設定、アカウント上限、データベース接続上限、ストレージ増加をあわせて確認してください。[スケーリング](/deploy/scaling)、[メトリクス](/observability/metrics)、[料金](https://lizard.build/pricing)を使って、設定済み容量と実測使用量を比較してください。 diff --git a/_locales/ja/platform/storage-and-recovery.mdx b/_locales/ja/platform/storage-and-recovery.mdx new file mode 100644 index 0000000..359e1e6 --- /dev/null +++ b/_locales/ja/platform/storage-and-recovery.mdx @@ -0,0 +1,53 @@ +--- +description: "アプリケーションデータと sandbox ファイルのためのストレージを選択します。リソースを削除または置き換える前に、アタッチ、ホスト障害、エクスポート、復旧について理解してください。" +--- + + + +# ストレージと復旧 + +プロセスの再起動、新しいデプロイ、またはホスト障害をまたいで保持する必要があるデータに応じてストレージを選択してください。これらはそれぞれ異なるイベントです。永続ストレージ自体は、バックアップ、復元ポイント、高可用性を提供しません。 + +| データ | 保管場所 | 境界 | +|---|---|---| +| アプリケーションレコード | Managed Postgres または別のデータベース | 再起動と、削除または破損したデータの復元は別です。別個のエクスポートおよび復元経路をテストしてください。 | +| キャッシュおよびキューデータ | Managed Redis | ワークロードが状態を再構築できるのか、独自の復旧計画が必要なのかを判断してください。 | +| アプリケーション間で共有されるファイル | Managed Object Storage | 非公開データをアップロードする前に、bucket のアクセス ポリシーを設定してください。自動作成される `default` bucket は public-read です。 | +| 後続の Sandboxes で必要なファイル | Persistent Volumes、`/data` にマウント | 一度にアタッチできる sandbox は 1 つだけです。volume はその node 上に残ります。 | +| 一時的な sandbox ファイル | `/data` の外側にある guest filesystem | sandbox の終了後や guest の置き換え後に残っていることを期待しないでください。 | +| 一時停止したプロセス状態 | ホストメモリ | 一時停止は永続的なスナップショットではありません。ホスト障害が発生するとその状態は失われます。 | + + + +## sandbox の終了後もファイルを保持する + +同じ project に Persistent Volumes を作成し、sandbox の作成時にアタッチして、`/data` の配下に書き込んでください。volume を次の sandbox にアタッチする前に、最初の sandbox を終了してください。[完全な例](/sandboxes/volumes)を参照してください。 + + + +## データベースの復元を計画する + +データを変更する移行またはリリースの前に: + +1. 使用中のデータベースとバージョンに対するエクスポート方法を選択します。 +2. 変更対象のリソースとは別の場所にエクスポートを保存します。 +3. 別個のテスト用データベースに復元し、アプリケーションがそれを読み取れることを確認します。 +4. 復元にかかる時間と、エクスポートに含まれる最新データを記録します。 + +データベースがマネージドであることを理由に、定期バックアップ、ポイントインタイムリカバリ、マルチノード レプリケーション、または復元時間の保証を想定しないでください。現在のサービス契約と、そのリソースで利用できる制御を確認してください。 + + + +## 環境参照 + +アプリケーションは、環境参照からデータベース接続を読み取るべきです。接続文字列は認証情報です。更新を確認するためにそれを出力するのは避けてください。`SELECT 1` のような接続確認は、shell 内で変数を見るよりも多くを証明します。 + + + +## 関連ガイド + +- [Managed Postgres](/addons/postgres) +- [Managed Redis](/addons/redis) +- [Managed Object Storage](/addons/storage) +- [Persistent Volumes](/sandboxes/volumes) +- [デプロイの復旧](/concepts/deployments#failed-releases-and-recovery) diff --git a/_locales/ja/sandboxes/_meta.ts b/_locales/ja/sandboxes/_meta.ts new file mode 100644 index 0000000..298257a --- /dev/null +++ b/_locales/ja/sandboxes/_meta.ts @@ -0,0 +1,8 @@ +export default { + index: "概要", + quickstart: "クイックスタート", + 'sdk-reference': "SDK リファレンス", + 'code-interpreter': "コード インタープリタ", + volumes: "Persistent Volumes", + dashboard: "ダッシュボード", +}; diff --git a/_locales/ja/sandboxes/code-interpreter.mdx b/_locales/ja/sandboxes/code-interpreter.mdx new file mode 100644 index 0000000..7dfeacd --- /dev/null +++ b/_locales/ja/sandboxes/code-interpreter.mdx @@ -0,0 +1,111 @@ +--- +description: "CodeSandbox は呼び出し間で状態を持つカーネルを維持するため、変数や import が保持されます。Python、JavaScript、Bash を、エージェントと同じように実行できます。" +--- + + + +# コード インタープリタ + +`CodeSandbox` は通常の[sandbox](/sandboxes)を **stateful kernel** で拡張したものです。Jupyter notebook のように、変数、import、関数定義が呼び出し間で保持されます。AI エージェントがコードを段階的に生成して実行する場合に適したツールです。 + +これは `code-interpreter-v1` テンプレート（Python 3.14 + Node.js 26、ポート 8080 でコード実行 API を提供）から起動し、標準で **Python、JavaScript、Bash** をサポートしています。 + + + +## コードを実行する + +```ts +import { CodeSandbox } from '@lizard-build/sdk'; + +// Every sandbox belongs to a project — usage is metered per project +const sandbox = await CodeSandbox.create({ project: 'my-project' }); // defaults to 'code-interpreter-v1' + +await sandbox.runCode('x = 42'); +const result = await sandbox.runCode('print(x * 2)'); +console.log(result.stdout); // "84\n" — x survived from the previous call + +await sandbox.kill(); +``` + +`runCode(code, opts?)` は `Execution` を返します: + +| フィールド | 説明 | +|---|---| +| `stdout` / `stderr` | 取得された出力ストリーム | +| `results` | リッチな結果（値、および生成された画像 / グラフ） | +| `error` | コードが例外を投げた場合の `ExecutionError`（`name`、`message`、`traceback`） | +| `executionCount` | カーネルの単調増加カウンター | + + + +## 言語を選ぶ + +デフォルトは Python です。別のランタイムで 1 回だけ実行するには、`language` を渡します: + +```ts +const js = await sandbox.runCode('1 + 1', { language: 'javascript' }); +console.log(js.results[0].data); // "2" + +await sandbox.runCode('echo "$(uname -s)"', { language: 'bash' }); +``` + + + +## 出力をストリーミングする + +実行時間の長いセルでは、結果を待つ代わりに、生成される stdout/stderr をその場でストリーミングできます: + +```ts +await sandbox.runCode('for i in range(5): print(i)', { + onStdout: (line) => process.stdout.write(line), + onStderr: (line) => process.stderr.write(line), + onResult: (r) => console.log('result:', r), + onError: (e) => console.error('error:', e.name, e.message), +}); +``` + + + +## 分離されたコンテキスト + +**context** は同じ sandbox 内の独立した名前空間です。変数が衝突しないよう、エージェントのセッションごと、またはユーザーごとに 1 つ使ってください。 + +```ts +const a = await sandbox.createContext({ language: 'python' }); +const b = await sandbox.createContext({ language: 'python' }); + +await sandbox.runCode('secret = 1', { context: a }); +await sandbox.runCode('print(secret)', { context: b }); // NameError — b never saw it + +await sandbox.listContexts(); +await sandbox.restartContext(a); // clear all variables/state +await sandbox.deleteContext(b); // free its resources +``` + +`runCode` には **`context`** と **`language`** の**どちらか一方**だけを渡し、両方は渡さないでください。context にはすでに言語が紐付いています。 + + + +## セッションをチェックポイントする + +`CodeSandbox` は sandbox なので、[一時停止と再開](/sandboxes/quickstart#pause-and-resume) は同じように機能します。重い依存関係スタックを一度だけインストールし、一時停止して、後でカーネル状態を保ったまま再開できます: + +```ts +const sandbox = await CodeSandbox.create({ project: 'my-project' }); +await sandbox.runCode('import subprocess; subprocess.run(["pip", "install", "scikit-learn"])'); +const id = sandbox.sandboxId; +await sandbox.pause(); + +// Later — resume with packages and kernel variables already in place +const resumed = await CodeSandbox.connect(id); +const out = await resumed.runCode('import sklearn; print(sklearn.__version__)'); +console.log(out.stdout); +await resumed.kill(); +``` + + + +## 関連情報 + +- [SDK Reference](/sandboxes/sdk-reference) — すべての `CodeSandbox` メソッドと `runCode` オプション。 +- [Persistent Volumes](/sandboxes/volumes) — 単一の sandbox より長く保持されるストレージをアタッチします。 diff --git a/_locales/ja/sandboxes/dashboard.mdx b/_locales/ja/sandboxes/dashboard.mdx new file mode 100644 index 0000000..7b82e23 --- /dev/null +++ b/_locales/ja/sandboxes/dashboard.mdx @@ -0,0 +1,63 @@ +--- +description: "プロジェクトの Sandboxes ページから手動でサンドボックスを作成・確認します: API キー、ライブシェル、ライフサイクル制御、スナップショット、ボリューム。" +--- + + + +# Sandboxes ダッシュボード + +すべてのプロジェクトには、手動でサンドボックスを作成・確認するための **Sandboxes** ページがあります。これは、エージェントの環境のデバッグ、対話型シェルの取得、生成されたコードのスポットチェックに便利です。プロジェクトを開き、サイドバーで **Sandboxes** を選択します (`///sandboxes`)。 + +このページには、**Sandboxes**、**ボリューム**、**スナップショット** の 3 つのタブがあります。 + + + +## API キーを取得する + +まだサンドボックスを使ったことがない場合、空の状態画面で SDK 用の **API キー** を作成する手順が表示されます。キーは **1 回だけ** 表示されます。すぐにコピーしてください。後から再取得はできません。これを `LIZARD_API_KEY` として保存します（[Quickstart](/sandboxes/quickstart#authenticate) を参照）。 + + + +## サンドボックスを作成する + +**New サンドボックス** をクリックして、次を設定します: + +- **Snapshot** — 起動元となる[テンプレート](/sandboxes#templates)（`base` または `code-interpreter-v1`）。 +- **Location** — 実行するリージョン（デフォルトでは利用可能な最寄り）。 +- **Resources** — 現在のテンプレートは 4 vCPU と 4096 MiB RAM を使用します。これらは作成ごとに選べるサイズオプションではありません。 + +ここで作成したサンドボックスにはタイムアウトがありません。終了するまで実行され続けます。 + + + +## 実行中のサンドボックスを確認する + +サンドボックスを選択すると、2 つのタブがある詳細ドロワーが開きます。 + +**Overview** には、ID、テンプレート、ステータス、リージョン、CPU / メモリに加えて、次が表示されます: + +- **Exposed ports** — [`getHost`](/sandboxes/quickstart#exposing-a-port) で開いたすべてのポート。それぞれに、直接開けるコピー可能な公開 `https://…onlizard.com` URL が付きます。 +- **SSH access** — 利用可能な場合は、そのまま貼り付けられる `ssh root@ -p ` コマンドと生成されたパスワード。 + +**Terminal** では、ブラウザ内シェルから micro-VM に直接入れます（SSH ベース）。そのため、ダッシュボードを離れずに中を確認できます。 + +ライブのサンドボックスは、一覧で CPU とメモリのリアルタイム使用量を表示します。paused および stopped のものは 0 を表示します。 + + + +## ライフサイクル + +- **Kill サンドボックス**（詳細ドロワー内）は、サンドボックスを即座に終了し、そのリソースを解放します。これには、接続されている [volume](/sandboxes/volumes) の切り離しも含まれます。 +- **Pause / resume** は [SDK](/sandboxes/quickstart#pause-and-resume) から実行します。一時停止したサンドボックスはここでは **Paused** と表示され、オンデマンドのコンピュートは消費しません。 + + + +## スナップショット + +**スナップショット** タブには、サンドボックスが起動元にできるテンプレート、つまり組み込みの `base` と `code-interpreter-v1` が一覧表示されます。カスタムテンプレートのアップロードコマンドは、現在の公開 CLI には含まれていません。各項目には、デフォルトの vCPU / メモリと説明が表示されます。 + + + +## ボリューム + +**ボリューム** タブでは、[永続ストレージ](/sandboxes/volumes) を管理します: 名前とサイズを指定してボリュームを作成し、それぞれがどのサンドボックスに接続されているかを確認できます。 diff --git a/_locales/ja/sandboxes/index.mdx b/_locales/ja/sandboxes/index.mdx new file mode 100644 index 0000000..0110808 --- /dev/null +++ b/_locales/ja/sandboxes/index.mdx @@ -0,0 +1,86 @@ +--- +description: "サンドボックスは、数ミリ秒で起動し、その中でコードを実行して、破棄できる、分離された Firecracker micro-VM です。AI エージェントを支えるコンピュートの基本単位です。" +--- + +# Sandboxes + +**sandbox** は、必要に応じて起動し、その中でコードを実行し、完了したら終了できる、分離された Firecracker micro-VM です。それぞれが独自のファイルシステム、ネットワーク、プロセス名前空間を持つ完全な Linux 環境であり、起動は数分ではなく数ミリ秒です。 + +Sandboxes は、Lizard における AI エージェント、コードインタープリタ、eval、CI スタイルのジョブを支えるコンピュートの基本単位です。[service](/concepts/architecture) がリポジトリに結び付いた長寿命のデプロイであるのに対し、sandbox は **一時的で、プログラム可能で、使い捨て** です。アカウントで利用可能なキャパシティの範囲内で、各タスクごとに sandbox を作成します。 + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const { stdout } = await sandbox.process.exec('echo "hello from Lizard"'); +console.log(stdout); // hello from Lizard +await sandbox.kill(); +``` + + + +## sandbox を使うタイミング + +| **sandbox** を使う場合… | **service** を使う場合… | +|---|---| +| エージェントが信頼できないコードや生成されたコードを実行する必要がある | 常時稼働するアプリをデプロイする | +| タスクごとに新しく使い捨ての Linux 環境が欲しい | 安定した `..onlizard.com` URL と TLS が欲しい | +| 分離された多数のジョブを一度に並列実行したい | 常時稼働する単一のプロセスがある | +| ワークロードが短命または一時停止される | ワークロードが git 連携され、自動再デプロイされる | + +エージェントが sandbox 内で動作するアプリを生成した後、それを [`lizard up`](/deploy/upload) を使って永続的な service に昇格できます。Dockerfile は不要です。 + + + +## 高速な理由 + +- **Firecracker micro-VMs** — 各 sandbox ごとに個別の Linux ゲストが用意されます。アプリランタイムには異なる分離ルールがあります。ハードウェア仮想化によってゲストはホストから分離されます。信頼できないコードに対しては、認証情報とネットワークアクセスを管理してください。 +- **Pause and resume** — 一時停止すると micro-VM の vCPU は停止します。メモリ、ファイルシステム、実行中のプロセスはそのまま保持されるため、再開すると中断した場所から正確に再開されます。パッケージの再インストールやキャッシュの再ウォームは不要です。これにより、長時間動作するエージェントセッションが別々の呼び出しをまたいで維持されます。状態はディスクに書き込まれるのではなくホストのメモリに保持されるため、ホスト障害は越えられません。[pause & resume](/sandboxes/quickstart#pause-and-resume) を参照してください。 +- **テンプレートから起動** — 各ノードはテンプレートごとに golden snapshot を事前構築するため、`create` はコールドブートではなく復元です。 + + + +## テンプレート + +sandbox は **template**（ダッシュボードでは *snapshot* とも呼ばれます）から起動します。組み込みは 2 つあります。 + +| テンプレート | 内容 | 最適な用途 | +|---|---|---| +| `base` | Debian Linux、Node.js 26、Lizard CLI | 汎用シェルおよびビルド環境 | +| `code-interpreter-v1` | Python 3.14 + Node.js 26、ポート 8080 でコード実行用 HTTP API を提供 | AI コードインタープリタ — [`CodeSandbox`](/sandboxes/code-interpreter) で操作 | + +`base` がデフォルトです。公開 create API はこの 2 つの template 名を受け付けます。カスタム template のアップロードフローは公開されていません。 + + + +## ライフサイクル + +sandbox は 3 つの状態を移動します。 + +``` +create ──▶ running ⇄ paused ──▶ stopped + (killed or expired) +``` + +- **running** — ゲストはコマンドを実行し、ファイルを扱い、公開されたポートでサービスを提供できます。 +- **paused** — vCPU は停止します。ゲストのメモリとプロセス状態はホスト上に残ります。これは永続的なスナップショットでもバックアップでもありません。 +- **stopped** — sandbox は削除または期限切れによって終了しました。ローカルファイルシステムはもう利用できません。 + +SDK はデフォルトで 5 分の有効期間を送信します。生の create API は、期限なしとして `timeoutMs: 0` を受け付けます。スクリプトがクライアント間で同じように動作する必要がある場合は明示的なタイムアウトを渡し、タスク終了時に sandbox を解放してください。コマンドを実行しても有効期間はリセットされません。 + +Pause は、残りの実行時間を保持することを意図しています。元の期限を超える一時停止に依存する前に、[現在のライフサイクル issue](/platform/known-issues#sandbox-pause-and-expiration) を確認してください。永続化するファイルは [volume](/sandboxes/volumes) に置くべきです。一時停止中のゲストはホスト障害を越えて保持されません。 + +## Resources & limits + +すべての sandbox は固定の **4 vCPU / 4096 MiB RAM** で実行されます。公開 create API には sandbox ごとのサイズ設定はありません。各 sandbox は、その template のリソースを引き継ぎます。 + +リージョンは利用可能なキャパシティから自動選択されます。ダッシュボードでは固定できます。アプリのクォータと sandbox のキャパシティが同じ適用ルールを使うとは想定しないでください。[limits](/platform/limits) を参照してください。 + + + +## Sandboxes を操作する方法 + +| 表面 | 最適な用途 | ここから開始 | +|---|---|---| +| **SDK** (JS / Python) | エージェント、アプリ、スクリプト — [`CodeSandbox`](/sandboxes/code-interpreter) を使ったステートフルな多言語実行を含む | [Quickstart](/sandboxes/quickstart) · [SDK Reference](/sandboxes/sdk-reference) | +| **ダッシュボード** | 手動作成、ターミナル、SSH、モニタリング | [ダッシュボード](/sandboxes/dashboard) | diff --git a/_locales/ja/sandboxes/quickstart.mdx b/_locales/ja/sandboxes/quickstart.mdx new file mode 100644 index 0000000..9036005 --- /dev/null +++ b/_locales/ja/sandboxes/quickstart.mdx @@ -0,0 +1,237 @@ +--- +description: "Lizard SDK で最初の sandbox を起動: インストール、API キーの作成、プロジェクトの選択、コードの実行、ファイルの移動、ポートの公開、一時停止まで。" +--- + + + +# Sandboxes クイックスタート + +サンドボックスを起動し、その中でコードを実行し、ポートを公開して、Lizard SDK で一時停止します。 + + + +## インストール + +```bash +# JavaScript / TypeScript +npm install @lizard-build/sdk + +# Python +pip install lizard-sdk +``` + + + +## 認証 + +Sandboxes は **API キー** で認証します。ダッシュボードの **サンドボックス → 開始する → 新しいAPIキー** で作成してください。表示されるのは一度だけなので、すぐにコピーしてください。 + +環境変数に設定すると、SDK が自動的に読み取ります: + +```bash +export LIZARD_API_KEY="" +``` + +明示的に渡すこともできます: `Sandbox.create('base', { apiKey, project })`. + + + +## プロジェクトを選ぶ + +すべてのサンドボックスはプロジェクトに属します。利用量はプロジェクトごとに計測されるため、指定しないと API は作成を拒否します。プロジェクトは ID、slug、または名前で指定します。 + +`Lizard` クライアントは 1 つのプロジェクトに固定されるため、指定は一度だけで済みます: + +```ts +import { Lizard } from '@lizard-build/sdk'; + +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +from lizard import Lizard + +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +クライアントを保持したくない場合は、`Sandbox.create` でも同じ `project` オプションを使えます。以下では両方の形式を使います。 + + + +## 最初の sandbox + +**JavaScript / TypeScript** + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +// Boot from a template (default: 'base') in a project +const sandbox = await Sandbox.create('base', { project: 'my-project' }); + +// Run a command and wait for it to finish +try { + const result = await sandbox.process.exec('node -e "console.log(2 ** 10)"'); + console.log(result.stdout); // 1024 + console.log(result.exitCode); // 0 +} finally { + await sandbox.kill(); +} +``` + +**Python** + +```python +from lizard import Sandbox + +sandbox = Sandbox.create("base", project="my-project") + +# exec_ (trailing underscore) because `exec` is reserved in Python +try: + result = sandbox.process.exec_("python -c 'print(2 ** 10)'") + print(result.stdout) # 1024 +finally: + sandbox.kill() +``` + +`process.exec` は `{ stdout, stderr, exitCode }` を返します。コマンドの完了を待機します。長時間実行するプロセスをバックグラウンドで動かすには、末尾に `&` を付けてください。 + + + +## ファイルを扱う + +`sandbox.fs` は micro-VM filesystem に直接読み書きし、必要に応じて親ディレクトリを作成します。 + +```ts +await sandbox.fs.write('/app/server.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('hello from Lizard')).listen(3000); +`); + +const src = await sandbox.fs.read('/app/server.js'); +const entries = await sandbox.fs.list('/app'); // [{ name, path, type, size }] +await sandbox.fs.makeDir('/app/data'); +await sandbox.fs.remove('/app/old.log'); +``` + +| メソッド | 説明 | +|---|---| +| `fs.write(path, data)` | ファイルを書き込む — string または bytes; 親ディレクトリも作成 | +| `fs.read(path)` | ファイルを UTF-8 string として読み込む | +| `fs.list(path)` | ディレクトリエントリを一覧表示 | +| `fs.makeDir(path)` | ディレクトリと不足している親を作成 | +| `fs.remove(path)` | ファイルまたはディレクトリを削除 | + + + +## ポートを公開する + +サンドボックス内で HTTP サーバーを起動し、それに対する公開 HTTPS URL を取得します。トンネリングは不要です。 + +```ts +await sandbox.process.exec('node /app/server.js &'); // listen on :3000 + +const host = await sandbox.getHost(3000); +console.log(`Live at https://${host}`); +// https://-3000.sandbox..onlizard.com +``` + +`getHost(port)` はそのポートへのルートを登録し、hostname を返します。URL は公開され、TLS 終端されています。再度削除するにはダッシュボードを使用してください。 + + + +## 一時停止と再開 + +一時停止するとゲストの vCPU は凍結され、現在の状態はホストメモリに保持されます。永続的なスナップショットは書き込みません。元の期限を超えてセッションを保持する前に、[一時停止と期限切れの問題](/platform/known-issues#sandbox-pause-and-expiration) を確認してください。 + +```ts +// Set the environment up once +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +await sandbox.process.exec('npm install -g some-heavy-toolchain'); +const id = sandbox.sandboxId; + +await sandbox.pause(); // freeze the guest; see the lifecycle issue below + +// …minutes or hours later, from anywhere: +const resumed = await Sandbox.connect(id); // resumes guest state still held by the host +await resumed.process.exec('some-heavy-toolchain --version'); // already installed +await resumed.kill(); +``` + +`Sandbox.connect(id)` は一時停止された sandbox を自動的に再開します。すでに保持しているハンドルに対して `sandbox.resume()` を呼び出すこともできます。 + +**Python** + +```python +sandbox = Sandbox.create("base", project="my-project") +sandbox.process.exec_("pip install numpy pandas") +sandbox_id = sandbox.sandbox_id +sandbox.pause() + +resumed = Sandbox.connect(sandbox_id) # resumes guest state still held by the host +resumed.process.exec_("python -c 'import numpy'") +resumed.kill() +``` + + + +## タイムアウト + +sandbox に正のタイムアウトがある場合、その存続期間を過ぎると期限切れになります。SDK のデフォルトは 5 分です。作成時に `timeoutMs: 0` を指定すると有効期限を無効化できます。明示的な上限を設定し、タスク終了時に sandbox を解放してください。実行中のサンドボックスは次で調整できます: + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); // 10 min +await sandbox.setTimeout(30 * 60 * 1000); // extend to 30 min from now +``` + +一時停止は残りの実行時間を凍結することを意図していますが、現在の [lifecycle issue](/platform/known-issues#sandbox-pause-and-expiration) ではバックエンドのリリース確認が必要です。データ保持のために無制限の一時停止を当てにしないでください。 + + + +## サンドボックスを管理する + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const info = await sandbox.getInfo(); // { sandboxId, template, startedAt, endAt, … } + +const all = await Sandbox.list(); // every running sandbox for this account +await sandbox.kill(); +``` + + + +## 完全な例 + +スクリプトを書き込み、それを実行し、結果を配信し、後で呼び出すためにゲストを一時停止するエージェント: + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 15 * 60 * 1000 }); + +try { + await sandbox.fs.write('/app/app.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('ok')).listen(3000); + `); + await sandbox.process.exec('node /app/app.js &'); + + const host = await sandbox.getHost(3000); + const res = await fetch(`https://${host}`); + console.log(await res.text()); // ok + + await sandbox.pause(); // resume later with Sandbox.connect(sandbox.sandboxId) +} catch (err) { + await sandbox.kill(); + throw err; +} +``` + + + +## 次のステップ + +- **[SDK Reference](/sandboxes/sdk-reference)** — すべての `Sandbox`、`CodeSandbox`、`Volume` メソッド。 +- **[コード インタープリタ](/sandboxes/code-interpreter)** — 状態を保持するマルチ言語コードを実行。 +- **[Persistent Volumes](/sandboxes/volumes)** — 単一のサンドボックスより長く存続するストレージをアタッチ。 diff --git a/_locales/ja/sandboxes/sdk-reference.mdx b/_locales/ja/sandboxes/sdk-reference.mdx new file mode 100644 index 0000000..0c4ad84 --- /dev/null +++ b/_locales/ja/sandboxes/sdk-reference.mdx @@ -0,0 +1,144 @@ +--- +description: "JavaScript と Python 向け Lizard SDK のすべてのクラスとメソッド: Lizard、サンドボックス、CodeSandbox、ボリューム。オプションと戻り値の型も含みます。" +--- + + + +# SDK リファレンス + +`@lizard-build/sdk` (JS/TS) と `lizard-sdk` (Python) パッケージは、ほとんどのエージェント、アプリ、スクリプトが sandbox を操作するために使用します。このページではすべてのクラスとメソッドを一覧化しています。手順の説明は [クイックスタート](/sandboxes/quickstart) を参照してください。 + + + +## インストールと認証 + +```bash +npm install @lizard-build/sdk # JavaScript / TypeScript +pip install lizard-sdk # Python +``` + +SDK は環境変数から `LIZARD_API_KEY` を読み取るか、`Sandbox.create` / `Sandbox.connect` に明示的な `apiKey` オプションを受け取ります。キーの作成方法は [Quickstart → Authenticate](/sandboxes/quickstart#authenticate) を参照してください。 + +すべてのサンドボックスは **プロジェクト** にも属します。使用量はプロジェクトごとに計測されるため、これを指定しない作成は拒否されます。 + +## `Lizard` + +1 つのプロジェクトに固定されたクライアントです。毎回の呼び出しごとではなく、一度だけ project を指定すれば済みます。 + +| メンバー | 説明 | +|---|---| +| `new Lizard({ project, apiKey?, apiUrl?, timeoutMs? })` | クライアントを作成します。`project` は必須です。プロジェクトの ID、slug、または名前を指定します（Python では `Lizard(project=…)`）。 | +| `lizard.create(template?, options?)` | クライアントの project で サンドボックスを起動します。 | +| `lizard.connect(sandboxId)` | ID で sandbox に接続し、一時停止中なら自動的に再開します。 | +| `lizard.list()` | アカウントの実行中 sandbox をすべて一覧表示します。 | +| `lizard.projectId()` | クライアントのプロジェクト参照をその ID に解決します（最初の呼び出し後はキャッシュされます）。 | + +```ts +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +キーでアクセス可能なプロジェクトに一致しないプロジェクト参照は、sandbox が起動される前にエラーとなり、参照可能な project の一覧が表示されます。 + +> 末尾にアンダースコアが付く Python のメソッド名（`exec_`）は予約語との衝突を避けるためのもので、プロパティは camelCase（`sandboxId`）ではなく snake_case（`sandbox_id`）です。以下の例では JS/TS 名を使用しています。メソッドシグネチャはインストール済みの Python パッケージを確認してください。 + +## `Sandbox` + +| メンバー | 説明 | +|---|---| +| `Sandbox.create(template?, options?)` | サンドボックスを起動します。`template` の既定値は `'base'` です。`options.project` には課金対象のプロジェクトを指定します。 | +| `Sandbox.connect(sandboxId)` | ID で sandbox に接続し、一時停止中なら自動的に再開します。 | +| `Sandbox.list()` | アカウントの実行中 sandbox をすべて一覧表示します。 | +| `sandbox.sandboxId` | sandbox の ID（Python では `sandbox_id`）。 | +| `sandbox.process.exec(cmd)` | コマンドを実行して完了まで待機します（Python では `process.exec_`）。`{ stdout, stderr, exitCode }` を返します。 | +| `sandbox.fs.write(path, data)` | ファイルを書き込みます。文字列または bytes に対応し、親ディレクトリも作成します。 | +| `sandbox.fs.read(path)` | ファイルを UTF-8 文字列として読み取ります。 | +| `sandbox.fs.list(path)` | ディレクトリエントリを一覧表示 → `[{ name, path, type, size }]`。 | +| `sandbox.fs.makeDir(path)` | ディレクトリと不足している親ディレクトリを作成します。 | +| `sandbox.fs.remove(path)` | ファイルまたはディレクトリを削除します。 | +| `sandbox.getHost(port)` | `port` へのルートを登録し、TLS 終端された公開ホスト名を返します。 | +| `sandbox.pause()` | guest vCPU を停止し、状態を host メモリに保持します。元の期限を超えて一時停止に依存する前に、[lifecycle status](#lifecycle-status) を確認してください。 | +| `sandbox.resume()` | 一時停止した sandbox をその場で再開します。 | +| `sandbox.setTimeout(ms)` | 実行中 sandbox の残りライフタイムをミリ秒単位で設定します（最小 1000）。 | +| `sandbox.getInfo()` | メタデータを取得 → `{ sandboxId, template, startedAt, endAt, … }`。 | +| `sandbox.kill()` | sandbox を即座に終了し、リソースを解放します。 | + +### `Sandbox.create(template?, options?)` + +| オプション | タイプ | デフォルト | 注記 | +|---|---|---|---| +| `template` | string | `'base'` | `'base'` または `'code-interpreter-v1'` — サポートされている 2 つの [templates](/sandboxes#templates) | +| `project` | string | — | **必須。** 課金対象のプロジェクトを指定します。ID、slug、または名前を指定します（Python では `project`）。`Lizard` クライアント経由では不要です。 | +| `projectId` | string | — | 正確な project ID。`project` の解決をスキップします | +| `timeoutMs` | int | SDK の既定値 5 分 | ライフタイム（ms） | +| `region` | string | auto | region に固定します | +| `volumeId` | string | — | `/data` に [volume](/sandboxes/volumes) をアタッチします | +| `apiKey` | string | `LIZARD_API_KEY` 環境変数 | 明示的な API キー。環境変数より優先されます | + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); +``` + +## `CodeSandbox` + +状態を保持するカーネルで `Sandbox` を拡張したものです。完全な手順は [コード インタープリタ](/sandboxes/code-interpreter) を参照してください。 + +| メンバー | 説明 | +|---|---| +| `CodeSandbox.create(options?)` | コードインタープリターを起動します（既定では `code-interpreter-v1` template を使用）。`Sandbox.create` と同じ `project` オプションを受け取ります。 | +| `CodeSandbox.connect(sandboxId)` | 既存のコードインタープリター サンドボックスに接続し（必要なら自動再開し）ます。 | +| `sandbox.runCode(code, opts?)` | カーネルでコードを実行します。`Execution` を返します。 | +| `sandbox.createContext(opts)` | 分離された namespace を作成します — `{ language }`。 | +| `sandbox.listContexts()` | サンドボックスのコンテキストを一覧表示します。 | +| `sandbox.restartContext(context)` | コンテキスト内のすべての変数 / 状態をクリアします。 | +| `sandbox.deleteContext(context)` | コンテキストのリソースを解放します。 | + +### `runCode(code, opts?)` + +| オプション | 説明 | +|---|---| +| `language` | 単発呼び出し用のランタイム — `'python'`（既定）、`'javascript'`、または `'bash'`。`context` とは同時に指定できません。 | +| `context` | 既定のコンテキストではなく、特定の分離コンテキスト内で実行します。`language` とは同時に指定できません。 | +| `onStdout` / `onStderr` | 生成される出力を行単位でストリーミングします。 | +| `onResult` | 各リッチ結果（値、生成された画像 / グラフ）ごとに呼び出されます。 | +| `onError` | コードが例外を投げた場合に `ExecutionError` を受け取って呼び出されます。 | + +`Execution` を返します: + +| フィールド | 説明 | +|---|---| +| `stdout` / `stderr` | キャプチャされた出力ストリーム | +| `results` | リッチ結果（値、および生成された画像 / グラフ） | +| `error` | コードが例外を投げた場合の `ExecutionError`（`name`、`message`、`traceback`） | +| `executionCount` | カーネルの単調増加カウンタ | + +## `Volume` + +完全な手順は [Persistent Volumes](/sandboxes/volumes) を参照してください。 + +| メンバー | 説明 | +|---|---| +| `Volume.create(projectId, name, options)` | volume を作成します。`options.sizeGb` の既定値は `5` です。 | +| `Volume.list(projectId)` | project 内の volume を一覧表示 → `[{ id, name, sizeGb, status, attachedTo, … }]`。 | +| `Volume.get(projectId, volumeId)` | 既存の volume へのハンドルを取得します。 | +| `volume.getInfo(projectId)` | メタデータとアタッチ状態を取得します。 | +| `volume.delete(projectId)` | volume を削除します — 先にデタッチされている必要があります。 | + + + +## 関連項目 + +- [Quickstart](/sandboxes/quickstart) — インストール、認証、完全な手順。 +- [コード インタープリタ](/sandboxes/code-interpreter) — `CodeSandbox` ガイド。 +- [Persistent Volumes](/sandboxes/volumes) — `Volume` ガイド。 + + + +## ライフサイクルステータス + +元の期限を超えてセッションを維持するために pause に依存する前に、[known issues](/platform/known-issues#sandbox-pause-and-expiration) を読んでください。pause は guest の状態を host メモリに保持しますが、永続的なバックアップではありません。 diff --git a/_locales/ja/sandboxes/volumes.mdx b/_locales/ja/sandboxes/volumes.mdx new file mode 100644 index 0000000..29487c5 --- /dev/null +++ b/_locales/ja/sandboxes/volumes.mdx @@ -0,0 +1,79 @@ +--- +description: "サンドボックスの再起動後もチェックポイント、weights、または作業ディレクトリを保持するために、/data にボリュームをアタッチします。ボリュームの作成、アタッチ、管理を行います。" +--- + +# Persistent Volumes + +Sandboxes は一時的です — 停止または期限切れになると、そのファイルシステムは失われます。**volume** は、単一のサンドボックスより長く存続する永続的なブロックストレージです。サンドボックスの再起動後もデータ（チェックポイント、モデルの weights、作業ディレクトリ）を保持するには、これをアタッチします。 + +ボリュームは**同時に 1 つのサンドボックス**にアタッチされ、micro-VM 内の **`/data`** にマウントされます。ボリュームは存在するノードに固定されるため、それをアタッチするサンドボックスも同じノードにスケジュールされます。 + + + +## 作成とアタッチ + +ボリュームをアタッチするには、サンドボックスの請求先プロジェクトとあわせて、その ID を `Sandbox.create` に渡します。`/data` 配下に書き込まれたものは、サンドボックスが終了した後も保持されます。 + +```ts +import { Sandbox, Volume } from '@lizard-build/sdk'; + +// Create a 10 GB volume in a project (default size: 5 GB) +const volume = await Volume.create('proj_123', 'agent-workdir', { sizeGb: 10 }); + +// Attach it to a sandbox — mounted at /data +const sandbox = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + await sandbox.fs.write('/data/state.json', JSON.stringify({ step: 1 })); +} finally { + await sandbox.kill(); // the volume persists +} + +// A later sandbox re-attaches and sees the data +const next = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + console.log(await next.fs.read('/data/state.json')); // {"step":1} +} finally { + await next.kill(); +} +``` + + + +## ボリュームの管理 + +```ts +await Volume.list('proj_123'); // [{ id, name, sizeGb, status, attachedTo, … }] +const v = await Volume.get('proj_123', 'vol_abc'); +await v.getInfo('proj_123'); +await v.delete('proj_123'); // must be detached first +``` + +| メソッド | 説明 | +|---|---| +| `Volume.create(projectId, name, { sizeGb })` | ボリュームを作成します（デフォルト 5 GB） | +| `Volume.list(projectId)` | プロジェクト内のボリュームを一覧表示します | +| `Volume.get(projectId, volumeId)` | 既存のボリュームへのハンドルを取得します | +| `volume.getInfo(projectId)` | メタデータとアタッチ状態を取得します | +| `volume.delete(projectId)` | ボリュームを削除します（未アタッチである必要があります） | + + + +## ダッシュボード内 + +ボリュームは、プロジェクトの **Sandboxes → ボリューム** タブにあります。名前とサイズを指定して作成できます。テーブルには各ボリュームのサイズ、ステータス（`available` / `attached`）、およびそれを保持しているサンドボックスが表示されます。サンドボックスが停止または期限切れになると、ボリュームは自動的に `available` に戻されます。[ダッシュボード](/sandboxes/dashboard) ガイドを参照してください。 + + + +## 注意 + +- ボリュームは同時に **1 つのサンドボックス**にしかアタッチできません。すでにアタッチされているボリュームをアタッチしようとすると、競合が返されます。 +- サンドボックスを削除する（または期限切れにする）と、ボリュームは**デタッチ**されます — 削除はされません。データは次回のアタッチに備えて保持されます。 +- ストレージを解放するには、ボリューム自体を削除してください。 +- 一時停止中のサンドボックスもアタッチを保持します。Persistent Volumes はノードローカルストレージを使用します。ノード障害後に復旧する必要があるデータはエクスポートしてください。[ストレージとリカバリ](/platform/storage-and-recovery) を参照してください。 + + + +## 関連項目 + +- [SDK Reference](/sandboxes/sdk-reference) — すべての `Volume` メソッド。 +- [Quickstart](/sandboxes/quickstart) — サンドボックス作成時にボリュームをアタッチします。 diff --git a/_locales/ja/studio/_meta.ts b/_locales/ja/studio/_meta.ts new file mode 100644 index 0000000..5c0e768 --- /dev/null +++ b/_locales/ja/studio/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'getting-started': "Lizard Studioをインストール", +}; diff --git a/_locales/ja/studio/getting-started.mdx b/_locales/ja/studio/getting-started.mdx new file mode 100644 index 0000000..6b81de1 --- /dev/null +++ b/_locales/ja/studio/getting-started.mdx @@ -0,0 +1,145 @@ +--- +title: "Claude Code と ChatGPT 用に Lizard Studio をインストールする" +description: "Chrome に Lizard Studio をインストールし、Claude Code または ChatGPT をローカルプロジェクトに接続して、最初の Web サイト編集を行います。セットアップガイドに従ってください。" +--- + + + +# Lizard Studio をインストールする + +Lizard Studio は、Claude Code または ChatGPT を構築中のページに接続する無料の Chrome 拡張機能です。ページの横にチャットを開き、要素を選択して、ローカルプロジェクト内のファイルをエージェントに編集させるよう依頼できます。この拡張機能には、ページ調査、注釈、ルーラー、カラーピッカー、ブラウザデバッグツールが含まれています。 + +このガイドでは、インストールから、ページを更新しても維持される 1 回のソース編集までを案内します。ダウンロード可能な例については、[Claude Code のビジュアル編集ガイド](https://lizard.build/blog/claude-code-visual-editor)を参照してください。 + + + +## 必要なもの + +- macOS、Windows、または Linux 上の Google Chrome。 +- Node.js と npm。ローカルホストは Node.js 18 以降を必要とします。選択したエージェントでは、より高いバージョンが必要な場合があります。両方がサポートする Node.js バージョンを使用してください。 +- Claude Code または ChatGPT 用のローカル CLI。自分のアカウントでサインインしている必要があります。 +- ローカルのプロジェクトフォルダー。ブラウザでソース編集を確認するには、そのプロジェクトの開発サーバーを起動し、その URL を開きます。 + +拡張機能とホストは無料で、MIT ライセンスです。モデルの利用には、プロバイダーのアカウント要件、制限、料金が適用されます。Lizard Studio を使うために Lizard アカウントは不要です。 + + + +## 1. Chrome 拡張機能を追加する + +[Chrome ウェブストアの Lizard Studio](https://chromewebstore.google.com/detail/kgbaeoalmkabpoglpjcdmppdmcipfdeh)を開き、**Chrome に追加** を選択します。ツールバーからすぐ開きたい場合は、拡張機能を固定してください。 + +ツールバーにはデザインツールがあり、Chrome のサイドパネルにはチャットが表示されます。ストアからのインストールではデベロッパーモードは不要です。 + + + +## 2. エージェントをインストールする + +使用したいエージェントを選んでください。もう一方は後から追加できます。 + +Claude Code の場合は、[公式セットアップガイド](https://code.claude.com/docs/en/setup)に従ってください。ターミナルでインストールを確認します。 + +```bash +claude --version +``` + +Lizard Studio で ChatGPT を使う場合は、Codex CLI をインストールします。 + +```bash +npm install -g @openai/codex +codex --version +``` + +Lizard Studio は、このエージェントをインターフェース上で **ChatGPT** と表示します。パッケージ名とターミナルコマンドでは **Codex** という名前を使います。これはプロジェクトに接続されたローカルのコーディングエージェントであり、chatgpt.com の Web サイトを埋め込むものではありません。 + +続行する前に、選択したエージェントを開いてサインイン手順を完了してください。サポートされている接続方法については、[Lizard Studio README](https://github.com/lizard-build/lizard-studio#setup)を参照してください。 + + + +## 3. ローカルホストをインストールする + +ターミナルで次のコマンドを 1 回実行します。 + +```bash +npx @lizard-build/lizard-studio-host install +``` + +このホストは、Chrome 拡張機能をコンピューター上のエージェントに接続します。インストーラーはホストを `~/.lizard-studio/host` にコピーし、ブラウザに登録します。Node.js はインストールしたままにしてください。ブラウザはホストの起動にそれを使用します。 + +インストール後、拡張機能のサイドパネルを開き直してください。既存のホストを更新した場合は、新しいチャットを開始する前にパネルを開き直してください。 + + + +## 4. ページをそのプロジェクトに接続する + +通常使っているコマンドで、プロジェクトの開発サーバーを起動します。表示された URL を Chrome で開き、そのタブで Lizard Studio を開きます。 + +チャットを開始し、**Claude Code** または **ChatGPT** を選び、このプロジェクトのソースコードを含むフォルダーを選択します。各チャットは、それぞれ独自のプロジェクトフォルダーと権限を保持します。正しいページを表示しているタブがあるだけでは、どのローカルリポジトリをエージェントが変更すべきかは伝わりません。 + +編集を依頼する前に、読み取り専用のリクエストで接続を確認してください。 + +```text +Read this page's title and inspect its main heading. Tell me which +local project folder you are using. Do not change any files yet. +``` + +エージェントが誤ったフォルダー名を示した場合は、続行する前に選択を修正してください。 + + + +## 5. 要素を選択して 1 つ編集する + +ページツールバーで **Selector** を選び、変更したい要素をクリックします。選択内容がチャットにコンテキストとして追加されます。複数の要素にまたがる視覚的な問題の場合は、**Annotate** を使って範囲を示し、スクリーンショットをチャットに追加してください。 + +結果を測定できるリクエストを試してください。 + +```text +Find the source for the selected card's action row. Set the gap +between its buttons to 24px in the project files. Keep the button +labels and colors unchanged. Show the diff, then inspect the +rendered row to check its computed gap. +``` + +提案されたファイル変更を確認し、権限コントロールを使って必要な作業を承認してください。どの操作に個別のプロンプトが必要かは、権限モードによって決まります。 + +開発サーバーがページを再読み込みしたら、結果を確認します。自動で再読み込みされない場合は、Chrome を更新してください。 + + + +## 6. 編集が維持されることを確認する + +一時的な DOM 編集は、更新するまでは正しく見えることがあります。ソース編集は、開発サーバーが配信するファイルを変更します。 + +エディターでファイル差分を確認するか、プロジェクトフォルダーから `git diff` を実行してください。ページを更新し、同じ要素をもう一度確認します。上の例では、計算後の gap は引き続き `24px` である必要があります。変更を残す前に、デスクトップレイアウトと幅の狭いレイアウトの両方を確認してください。 + +ローカルプロジェクトを編集しても、デプロイ済みの Web サイトは更新されません。変更を本番公開したい場合は、別途デプロイしてください。 + + + +## 接続に失敗する場合 + +| 表示される内容 | 確認すること | +|---|---| +| サイドパネルがホストに接続できない | ホストインストーラーを実行し、Node.js が利用可能であることを確認してから、パネルを開き直してください。 | +| エージェントを起動できない | ターミナルで `claude --version` または `codex --version` を確認し、そのエージェントのログインを完了してください。 | +| エージェントはページを認識しているが、そのコードを見つけられない | 正しいローカルフォルダーを選択し、そのタブがそのプロジェクトの開発サーバーを使用していることを確認してください。 | +| 編集が更新時に消える | 差分を確認してください。エージェントが live DOM だけを変更した場合は、ソース変更を依頼してください。 | +| Chrome の設定ページでツールバーが表示されない | Chrome は `chrome://` ページ、新しいタブページ、Chrome ウェブストアではコンテンツスクリプトをブロックします。通常の Web サイトを開いてください。 | + +macOS では、`~/.lizard-studio/host` にあるホストの場所によって、Chrome が Desktop、Documents、Downloads 配下のホストを起動するときに遭遇する制限も回避できます。詳細は [README のホストに関する注記](https://github.com/lizard-build/lizard-studio#2-the-local-host-one-time)を参照してください。 + + + +## データの送信先 + +拡張機能とホストはコンピューター上で実行されます。選択したモデルプロバイダーは、そのエージェント経由で送信したリクエストを受け取ります。Lizard Studio は Lizard のチャットサーバーを使用せず、テレメトリーも収集しません。ローカルインストールであっても、クラウドモデルがプロンプトをローカルで処理することを意味するわけではありません。データ制限のあるプロジェクトで使用する前に、[Lizard Studio プライバシーポリシー](https://github.com/lizard-build/lizard-studio/blob/main/PRIVACY.md)を確認してください。 + + + +## 関連ガイド + +- [要素を選択して CSS を修正する](https://lizard.build/blog/claude-code-visual-editor) +- [ChatGPT を使ってローカル Web サイトを編集する](https://lizard.build/studio/chatgpt) +- [Lizard Studio と Chrome 上の Claude を比較する](https://lizard.build/studio/compare/claude-in-chrome) +- [Claude Code GUI を選ぶ](https://lizard.build/blog/claude-code-gui) + +セットアップは 2026 年 9 月 14 日時点の Lizard Studio ソースに対して確認されています。 diff --git a/_locales/ja/variables/_meta.ts b/_locales/ja/variables/_meta.ts new file mode 100644 index 0000000..1c82fc8 --- /dev/null +++ b/_locales/ja/variables/_meta.ts @@ -0,0 +1,5 @@ +export default { + index: "変数とシークレット", + references: "サービス間参照", + troubleshooting: "トラブルシューティング", +}; diff --git a/_locales/ja/variables/index.mdx b/_locales/ja/variables/index.mdx new file mode 100644 index 0000000..99d4728 --- /dev/null +++ b/_locales/ja/variables/index.mdx @@ -0,0 +1,112 @@ +--- +description: "サービスまたはプロジェクトのスコープで secrets を設定し、マージ時の優先順位と、どの値がビルドと実行中のコンテナに届くかを確認します。" +--- + + + +# 変数と Secrets + +Lizard は設定を **secrets** として保存します。これらには **service**（デフォルト）と **project**（`--global`）の 2 つのスコープがあり、定義された優先順位に従ってアプリの環境にマージされます。workspace レベルのグローバルスコープはありません。 + + + +## 変数の設定 + +`lizard secrets set` は可変長です。一度に 1 つでも複数でも設定できます。デフォルトでは **linked service** に書き込みます。 + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + +**project** スコープに書き込むには `--global` を追加します（プロジェクト内のすべてのサービスから参照できます）。 + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +## 一覧表示、削除、インポート + +```bash +lizard secrets list # current scope +lizard secrets list --show # reveal values +lizard secrets delete OLD_KEY ANOTHER_KEY # variadic +cat .env | lizard secrets import # import dotenv from stdin +``` + +すべてのフラグについては、[`lizard secrets` コマンドリファレンス](/cli/secrets)を参照してください。 + + + +## スコープ + +| スコープ | コマンド | 保存形式 | 表示対象 | +|-------|---------|-----------|------------| +| **サービス**（デフォルト） | `lizard secrets set K=v --service ` | `secrets.services[]` | そのサービスのみ | +| **プロジェクト**（グローバル） | `lizard secrets set K=v --global` | `secrets.shared` | プロジェクト内のすべてのサービス | + +**デフォルトでは service スコープを使ってください。** 侵害されたサービスは自身の環境を読み取れます。より広いスコープは、理由もなく公開される認証情報が増えることを意味します。`--global` は、`LOG_LEVEL`、`NODE_ENV`、feature flag、またはフロントエンドの `SENTRY_DSN` のような、secret ではなく公開されても問題ないと証明できる値に限って使ってください。値が secret かどうか迷う場合は、secret として扱い、service にスコープしてください。 + +データベースのような共有リソースでは、DSN を `--global` に置かないでください。代わりに、[reference](/variables/references) を使って利用側ごとにバインドしてください。 + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service worker +``` + +ローテーションは addon 側で一度行えば済み、すべての reference が更新されます。 + + + +## 優先順位 + +同じキーが複数の場所で定義されている場合、**最後に書き込まれたものが勝ちます**。 + +``` +addon-issued env < project secrets < project env < app env < app secrets < platform vars +``` + +したがって、**app secrets は project secrets を上書き**し、**platform variables**（`PORT`、`LIZARD_SERVICE_NAME`、`LIZARD_PROJECT_ID`、`LIZARD_PUBLIC_DOMAIN`）は最後に適用されるため、上書きできません。 + + + +## ビルド時と実行時 + +ほとんどの変数変更は **再ビルドなし** で反映されます。反映のためにサービスは再起動され、これには数秒かかります。例外は、イメージに焼き込まれるビルド時の値です。 + +- `VITE_*` と `NEXT_PUBLIC_*` の変更は、次回のデプロイ時に **再ビルドを強制** します。 + +[ビルド パイプライン → 再ビルド トリガー](/concepts/build-pipeline#what-triggers-a-rebuild) を参照してください。 + + + +## 確認 + +実行中のサービスが実際に何を参照しているか確認します。 + +```bash +lizard ssh --service api -- env +``` + +想定していた値が存在しない場合は、[Troubleshooting → secret または reference が表示されない](/variables/troubleshooting/reference-not-applied)を参照してください。 + + + +## ローカル開発 + +サービスの project + service secrets を注入した状態で、**ローカル** でコマンドを実行します（スクリプトや migration に便利です）。 + +```bash +lizard run --service api -- node scripts/seed.js +``` + +[`lizard run` と `lizard ssh` の違い](/cli/run#run-vs-ssh)を参照してください。 + + + +## 関連項目 + +- [サービス間参照](/variables/references) — 認証情報をコピー＆ペーストせずに、あるサービスから別のサービスの値を読み取ります。 +- [`lizard secrets`](/cli/secrets) — 完全なコマンドリファレンス。 diff --git a/_locales/ja/variables/references.mdx b/_locales/ja/variables/references.mdx new file mode 100644 index 0000000..013ec2b --- /dev/null +++ b/_locales/ja/variables/references.mdx @@ -0,0 +1,78 @@ +--- +description: "${{name.KEY}} 構文で、あるサービスやアドオンの値を別のサービスやアドオンから読み取ります。参照がデプロイ時にどのように解決されるか、そしてなぜコピーより優れているのかを説明します。" +--- + + + +# サービス間参照 + +参照を使うと、あるサービスやアドオンが、認証情報をコピー＆ペーストせずに別のサービスやアドオンの値を読み取れます。シークレットを1か所にまとめて保持でき、自動的にローテーションされます。 + + + +## 構文 + +``` +${{.}} +``` + +- `` — 対象のサービスまたはアドオン名（ダッシュボードに表示され、`lizard add -n` で使われるもの）。 +- `` — 対象のマージ済み環境内のキー。 + +値を受け付ける場所ならどこでも使えます。最も一般的なのはシークレットです: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + + + +## 解決の仕組み + +- 参照は、対象のマージ済み環境に対して**デプロイ時**に解決されます。 +- **ID** で保存されるため、あとで対象の名前を変更しても参照は壊れません。 +- **存在しない**対象またはキーへの参照は、**空文字列**に解決されます。デプロイは失敗しません。 +- エラーになるのは**循環**参照だけです。 + +> 存在しないキーは黙って空になるため、参照を設定したあとは、コンシューマーが実際に値を受け取ったかを必ず確認してください: +> ```bash +> lizard ssh --service api -- env | grep DATABASE_URL +> ``` + +参照が期待どおりに反映されない場合は、[トラブルシューティング → シークレットまたは参照が表示されない](/variables/troubleshooting/reference-not-applied) を参照してください。 + + + +## よくあるパターン + +**1つのアドオンを複数のサービスに接続する** — ローテーションがどこにでも伝播するよう、各コンシューマー側でバインドします: + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +``` + +**別のサービスの値を参照する** — たとえば、計算された URL やトークンを共有する場合: + +```bash +lizard secrets set UPSTREAM_URL='${{api.LIZARD_PUBLIC_DOMAIN}}' --service web +``` + +**同じ種類の2つ目のアドオンを参照する** — その自動生成された名前を使います: + +```bash +lizard secrets set CACHE_URL='${{redis-winter-otter.REDIS_URL}}' --service api +``` + + + +## なぜ `--global` を使わないのですか？ + +共有 DSN をプロジェクト（`--global`）スコープに置くと、必要のないものも含めて*すべて*のサービスに公開されます。参照を使えば、単一の信頼できる情報源としてのローテーションという利点はそのままに、各シークレットを実際に利用するサービスだけにスコープできます。[シークレットのスコープ](/variables#scoping) を参照してください。 + + + +## 関連項目 + +- [変数とシークレット](/variables) — スコープと優先順位。 +- [`lizard secrets`](/cli/secrets) — 完全なコマンドリファレンス。 diff --git a/_locales/ja/variables/troubleshooting/_meta.ts b/_locales/ja/variables/troubleshooting/_meta.ts new file mode 100644 index 0000000..7036516 --- /dev/null +++ b/_locales/ja/variables/troubleshooting/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'reference-not-applied': "シークレットまたは参照が表示されません", +}; diff --git a/_locales/ja/variables/troubleshooting/reference-not-applied.mdx b/_locales/ja/variables/troubleshooting/reference-not-applied.mdx new file mode 100644 index 0000000..82d6531 --- /dev/null +++ b/_locales/ja/variables/troubleshooting/reference-not-applied.mdx @@ -0,0 +1,71 @@ +--- +description: "シークレットまたは参照は設定されていますが、サービスからは見えていません。存在しないターゲットは空文字列として解決され、優先順位によって値が隠されることがあります。" +--- + + + +# シークレットまたは参照がサービスに反映されない + +シークレットまたは `${{name.KEY}}` 参照を設定して再デプロイしても、実行中のサービスでは期待した値が確認できないことがあります。 + + + +## これは何を意味するのか + +設定した値がサービスのマージ後の環境に一度も入っていないか、アプリの起動前にマージ処理で別の値に上書きされたことを意味します。 + + + +## なぜ起こるのか + +- **参照先のターゲットまたはキーが存在しません。** 存在しない service / addon 名への参照、またはその addon が公開していないキーへの参照は、デプロイを失敗させる代わりに **空文字列** として解決されます。通知するエラーは出ないため、サービスは空の値のまま起動します。 +- **より高い優先順位のものに上書きされました。** 値は固定順序でマージされます — `addon-issued env < project secrets < project env < app env < app secrets < platform vars` — そのため、project スコープの (`--global`) シークレットは、同じキーを持つ service スコープのシークレットに静かに隠されることがあります。また、プラットフォーム変数 (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) は常に優先され、まったく上書きできません。 +- **ビルド時の値を変更したのに再ビルドしていません。** ほとんどの変数変更は再ビルド不要で適用され、サービスはそれらを取り込むために再起動されます。例外は `VITE_*` と `NEXT_PUBLIC_*` の値で、これらはビルド済みアセットに埋め込まれるため、単なる再起動では新しい値は反映されません。サービスには新しいビルドが必要です。 + + + +## 考えられる解決策 + + + +### 実行中のサービスが実際に何を見ているか確認する + +これは信頼できる確認方法です。設定したつもりの値ではなく、稼働中コンテナの実際の環境を表示します。 + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + +キーが見つからない、または空の場合、参照先のターゲット / キーが誤っているか、そのスコープには何も設定されていません。`lizard ps` で addon または service 名を再確認し、キーについては addon の[ドキュメント化された変数](/addons)を確認してください。 + + + +### スコープの衝突を確認する + +両方のスコープのシークレットを一覧し、比較してください。 + +```bash +lizard secrets list --service api --show +lizard secrets list --global --show +``` + +**app secrets は project secrets を上書きする** ことに注意してください。同じキーに service スコープの値が存在する場合、`--global` で設定したものよりそちらが優先されます。 + + + +### ビルド時の変更後は再ビルドする + +変更したキーが `VITE_*` または `NEXT_PUBLIC_*` の場合、再起動ではなく実際の再ビルドを実行してください。 + +```bash +lizard redeploy --service api +``` + +[ビルド時と実行時](/variables#build-time-vs-runtime) および [ビルド パイプライン → 再ビルドをトリガーするもの](/concepts/build-pipeline#what-triggers-a-rebuild) も参照してください。 + + + +## 関連項目 + +- [変数 & Secrets](/variables) — スコープと優先順位。 +- [サービス間参照](/variables/references) — 参照構文と解決方法。 diff --git a/_locales/ru/_meta.ts b/_locales/ru/_meta.ts new file mode 100644 index 0000000..6468306 --- /dev/null +++ b/_locales/ru/_meta.ts @@ -0,0 +1,18 @@ +export default { + index: "Введение", + 'getting-started': "Быстрый старт приложения", + studio: "Lizard Studio", + 'framework-guides': "Руководства по фреймворкам", + guides: "Руководства", + platform: "Лимиты и операции", + concepts: "Основные понятия", + deploy: "Развертывание", + variables: "Переменные", + networking: "Сеть", + addons: "Управляемые аддоны", + sandboxes: "Sandboxes", + observability: "Наблюдаемость", + cli: "Справочник CLI", + dashboard: "Панель приложения", + agents: "Агенты для кодинга", +}; diff --git a/_locales/ru/addons/_meta.ts b/_locales/ru/addons/_meta.ts new file mode 100644 index 0000000..79ec927 --- /dev/null +++ b/_locales/ru/addons/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Обзор", + postgres: "Postgres", + redis: "Redis", + storage: "Object Storage (S3)", +}; diff --git a/_locales/ru/addons/index.mdx b/_locales/ru/addons/index.mdx new file mode 100644 index 0000000..337779c --- /dev/null +++ b/_locales/ru/addons/index.mdx @@ -0,0 +1,80 @@ +--- +description: "Создайте управляемые Postgres, Redis и S3-совместимое хранилище одной командой lizard add, а затем подключите их к сервисам по ссылке." +--- + + + +# Управляемые дополнения + +Lizard создаёт управляемые **Postgres**, **Redis** и **S3-совместимое объектное хранилище** одной командой. Каждое дополнение существует в рамках вашего проекта, предоставляет фиксированный набор переменных окружения и подключается к сервисам через [ссылки](/concepts/architecture#cross-resource-references). + + + +## Создание дополнения + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +## Имена + +**Первое** дополнение каждого типа получает в качестве имени само название типа — поэтому `${{postgres.DATABASE_URL}}` работает сразу после создания. Дополнительные дополнения того же типа получают сгенерированное имя, например `postgres-autumn-bear`. + +Псевдонимы типов не поддерживаются: ссылка должна содержать **фактическое** имя дополнения. Поскольку ссылки хранятся по идентификатору, имя дополнения можно изменить позже, не нарушая работу уже использующих его сервисов: + +```bash +lizard service rename --service postgres # addons rename through the same command +``` + + + +## Использование дополнения + +Ссылки на переменные дополнения можно использовать из любого сервиса. Ссылка разрешается во время развёртывания и автоматически обновляется при изменении учётных данных дополнения: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +Настройте область действия ссылки только для тех сервисов, которые её используют (см. [Ограничение области действия секретов](/variables#scoping)). + + + +## Переменные по типам + +| Дополнение | Переменные | +|-------|-----------| +| **postgres** | `DATABASE_URL`, `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`, `POSTGRES_USER`, `POSTGRES_DB`, `POSTGRES_PASSWORD` | +| **redis** | `REDIS_URL` | +| **s3** | `S3_ENDPOINT`, `S3_DEFAULT_BUCKET`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `S3_REGION` | + + + +## Просмотр данных в панели управления + +В [панели управления](/dashboard) есть браузер данных для каждого дополнения: редактор SQL и таблиц для Postgres, просмотр ключей для Redis и просмотр бакетов и объектов для S3. Вы сможете просматривать и изменять данные, не покидая Lizard. + + + +## Хранилище + +Объём томов данных дополнений можно только увеличивать. Чтобы увеличить ёмкость, используйте: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Руководства по типам + +- [Postgres](/addons/postgres) +- [Redis](/addons/redis) +- [Object Storage (S3)](/addons/storage) + +О том, зачем прототипу обычно нужны все три компонента сразу, см. [остальную часть стека, необходимого SaaS](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#the-rest-of-the-stack-a-saas-needs). diff --git a/_locales/ru/addons/postgres.mdx b/_locales/ru/addons/postgres.mdx new file mode 100644 index 0000000..b058be9 --- /dev/null +++ b/_locales/ru/addons/postgres.mdx @@ -0,0 +1,107 @@ +--- +description: "Создайте базу данных Managed Postgres на Lizard, подключите её к сервису по ссылке, запускайте миграции при развёртывании и увеличивайте объём её хранилища." +--- + +# Managed Postgres + +Управляемая база данных PostgreSQL, которую можно создать одной командой и подключить к сервисам по ссылке. + + + +## Создание + +```bash +lizard add postgres +``` + +Первое дополнение Postgres получает имя `postgres`, поэтому `${{postgres.DATABASE_URL}}` работает сразу. + + + +## Переменные окружения + +Дополнение предоставляет стандартный набор переменных подключения: + +| Переменная | Описание | +|----------|-------------| +| `DATABASE_URL` | Полная строка подключения (`postgres://…`) | +| `PGHOST` | Хост | +| `PGPORT` | Порт | +| `PGUSER` | Пользователь | +| `PGPASSWORD` | Пароль | +| `PGDATABASE` | Имя базы данных | +| `POSTGRES_USER` | Алиас пользователя | +| `POSTGRES_DB` | Алиас базы данных | +| `POSTGRES_PASSWORD` | Алиас пароля | + + + +## Подключение сервиса + +Укажите ссылку на строку подключения в сервисе-потребителе и выполните повторное развёртывание: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard redeploy --service api +``` + +Ссылка вычисляется при развёртывании и автоматически обновляется при изменении учётных данных дополнения — каждый сервис-потребитель получает новое значение при следующем развёртывании. + +Проверьте подключение, не выводя строку подключения: + +```bash +lizard run --service api -- sh -c 'psql "$DATABASE_URL" -c "SELECT 1"' +``` + + + +## Запуск миграций при развёртывании + +Используйте команду перед развёртыванием для запуска миграций. Сделайте миграции безопасными для повторного запуска и совместимыми как со старой, так и с новой версией приложения: + +```bash +lizard service set api --set preDeployCommand="npm run migrate" +lizard redeploy --service api +``` + +Для приложения Django используется команда `python manage.py migrate`; в разделе [Хостинг Python-приложений](https://lizard.build/blog/python-app-hosting#deploying-django) приведены её аналоги для Flask и FastAPI. + + + +## Просмотр данных и выполнение запросов + +Откройте **редактор Postgres** в панели управления (`lizard open`), чтобы выполнять SQL-запросы и просматривать таблицы напрямую. Для разовых локальных задач выполните команду, используя внедрённое в сервис окружение: + +```bash +lizard run --service api -- sh -c 'exec psql "$DATABASE_URL"' +``` + + + +## Увеличение объёма хранилища + +Объём хранилища данных можно только увеличивать: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Несколько баз данных + +При добавлении второго экземпляра Postgres для него генерируется имя, например `postgres-autumn-bear`. Укажите ссылку на него явно: + +```bash +lizard add postgres +lizard secrets set ANALYTICS_URL='${{postgres-autumn-bear.DATABASE_URL}}' --service api +``` + + + +## См. также + +- [Управляемые дополнения](/addons) — имена, ссылки и инструменты просмотра в панели управления. +- [Межсервисные ссылки](/variables/references) — синтаксис ссылок и порядок их вычисления. + +Сведения о планировании резервного копирования и восстановления см. в разделе [хранилище и восстановление](/platform/storage-and-recovery). При локальном использовании `lizard run` требуется `psql` и доступная точка подключения к базе данных; этот процесс не выполняется внутри развёрнутого сервиса. diff --git a/_locales/ru/addons/redis.mdx b/_locales/ru/addons/redis.mdx new file mode 100644 index 0000000..ce34798 --- /dev/null +++ b/_locales/ru/addons/redis.mdx @@ -0,0 +1,79 @@ +--- +description: "Добавьте экземпляр Managed Redis для кэширования, очередей, ограничения частоты запросов и pub/sub и подключите его к сервису с помощью одной ссылки." +--- + +# Managed Redis + +Управляемый экземпляр Redis для кэширования, очередей, ограничения частоты запросов и pub/sub. + + + +## Создание + +```bash +lizard add redis +``` + +Первое дополнение Redis называется `redis`, поэтому `${{redis.REDIS_URL}}` работает сразу. + + + +## Переменные окружения + +| Переменная | Описание | +|----------|-------------| +| `REDIS_URL` | Полная строка подключения (`redis://…`) | + + + +## Подключение сервиса + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard redeploy --service api +``` + +Ссылка разрешается при развёртывании и обновляется при смене учётных данных дополнения. + + + +## Типовые варианты использования + +- **Кэширование** — сохраняйте вычисленные результаты с ключом запроса. +- **Очередь / воркер** — используйте Redis вместе с [сервисом в режиме воркера](/deploy/workers), который обрабатывает задания. +- **Ограничение частоты запросов / сессии** — быстрое разделяемое состояние для [реплик](/deploy/scaling). + +```bash +# A worker that drains a Redis queue +lizard add -r your-org/worker -n jobs +lizard service set jobs --set containerPort=0 +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service jobs +lizard redeploy --service jobs +``` + + + +## Просмотр ключей + +Откройте **Браузер Redis** в панели управления (`lizard open`), чтобы просмотреть ключи и значения. Для локального доступа: + +```bash +lizard run --service api -- sh -c 'exec redis-cli -u "$REDIS_URL"' +``` + + + +## Расширение хранилища + +```bash +lizard scale --service redis --storage 4096 +``` + + + +## См. также + +- [Управляемые дополнения](/addons) — соглашения об именах, ссылки и браузеры в панели управления. +- [Фоновые воркеры](/deploy/workers) — использование Redis вместе с воркером, обрабатывающим очередь. + +`lizard run` запускает команду локально с выбранным окружением сервиса. Установите `redis-cli` локально и проверьте доступность конечной точки. \ No newline at end of file diff --git a/_locales/ru/addons/storage.mdx b/_locales/ru/addons/storage.mdx new file mode 100644 index 0000000..2d96345 --- /dev/null +++ b/_locales/ru/addons/storage.mdx @@ -0,0 +1,110 @@ +--- +description: "S3-совместимое объектное хранилище для загрузок, статических файлов и бэкапов. Получите публичный бакет и переменные подключения одной командой lizard add s3." +--- + + + +# Объектное хранилище (S3) + +S3-совместимое объектное хранилище для загрузок, статических файлов и бэкапов. При создании аддона `s3` автоматически создаётся **бакет с публичным чтением под именем `default`**, поэтому файлы можно отдавать сразу, без дополнительной настройки. + + + +## Создание + +```bash +lizard add s3 +``` + +Первый S3-аддон называется `s3`, поэтому `${{s3.S3_ENDPOINT}}` и подобные команды работают сразу. + + + +## Переменные окружения + +| Переменная | Описание | +|----------|-------------| +| `S3_ENDPOINT` | S3-совместимый URL эндпоинта | +| `S3_DEFAULT_BUCKET` | Имя автоматически созданного бакета (`default`) | +| `S3_ACCESS_KEY_ID` | Access key | +| `S3_SECRET_ACCESS_KEY` | Secret key | +| `S3_REGION` | Регион | + + + +## Подключение сервиса + +```bash +lizard secrets set \ + S3_ENDPOINT='${{s3.S3_ENDPOINT}}' \ + S3_DEFAULT_BUCKET='${{s3.S3_DEFAULT_BUCKET}}' \ + S3_ACCESS_KEY_ID='${{s3.S3_ACCESS_KEY_ID}}' \ + S3_SECRET_ACCESS_KEY='${{s3.S3_SECRET_ACCESS_KEY}}' \ + S3_REGION='${{s3.S3_REGION}}' \ + --service api +lizard redeploy --service api +``` + + + +## Использование AWS SDK + +Эндпоинт совместим с S3. Используйте **path-style** адресацию: + +```ts +import { S3Client } from "@aws-sdk/client-s3"; + +const s3 = new S3Client({ + endpoint: process.env.S3_ENDPOINT, + region: process.env.S3_REGION, + forcePathStyle: true, // required + credentials: { + accessKeyId: process.env.S3_ACCESS_KEY_ID!, + secretAccessKey: process.env.S3_SECRET_ACCESS_KEY!, + }, +}); +``` + + + +## Публичные файлы + +Объекты в любом **публичном** бакете доступны без аутентификации двумя способами: + +1. **Gateway URL** (показывается в дашборде): + ``` + https://s3-.onlizard.com/// + ``` +2. **Platform proxy** (хост дашборда, с долгими неизменяемыми заголовками кэша): + ``` + /api/s3//public// + ``` + +Все, что загружено в бакет `default`, сразу становится публичным по адресу: + +``` +/api/s3//public/default/ +``` + + + +## Обзор объектов + +Откройте **S3-браузер** в дашборде (`lizard open`), чтобы загружать, скачивать и управлять объектами и бакетами. + +> **Изменение ACL бакета** (переключение публичный/приватный) пока недоступно в CLI — управляйте ими через дашборд. + + + +## Увеличение хранилища + +```bash +lizard scale --service s3 --storage 16384 +``` + + + +## См. также + +- [Managed Addons](/addons) — именование, ссылки и браузеры в дашборде. +- [Межсервисные ссылки](/variables/references) — синтаксис ссылок и их разрешение. diff --git a/_locales/ru/agents.mdx b/_locales/ru/agents.mdx new file mode 100644 index 0000000..f1e9070 --- /dev/null +++ b/_locales/ru/agents.mdx @@ -0,0 +1,92 @@ +--- +description: "Управляйте Lizard с помощью AI-агента для кодирования: читайте Lizard Skill, узнавайте схемы команд через --json и развертывайте через Lizard CLI." +--- + + + +# Агенты для кодирования + +Lizard спроектирован так, чтобы им можно было управлять от AI-агентов для кодирования так же легко, как людьми. В CLI встроен **встроенный навык (skill)**, который обучает агента всей платформе, а каждая команда **самоописывается** через `--json`, поэтому агентам никогда не нужно угадывать. + + + +## Встроенный навык + +Авторитетное руководство по использованию находится внутри CLI и версионируется вместе с ним, поэтому оно всегда соответствует установленной версии. Агент читает его с помощью: + +```bash +lizard skills get core --json +``` + +Это возвращает `{ name, frontmatter, content, … }` — `content` является полным руководством (конвейер сборки, приоритет переменных окружения, аддоны, обнаружение, коды выхода). Связанные подкоманды: + +```bash +lizard skills list # available embedded skills +lizard skills get core # the core guide +lizard skills path # where skills are stored +``` + +Так как руководство поставляется в составе бинарника, `lizard upgrade` обновляет и инструкции агента. + + + +## Самоописывающиеся команды + +Агенты обнаруживают точную форму флагов во время выполнения вместо того, чтобы полагаться на запомненный синтаксис: + +```bash +lizard --help --json # full command tree + exit codes +lizard --help --json # a specific command's schema +``` + +См. [JSON и автоматизация](/cli/json). + + + +## Бутстраппинг в агенте + +Типичный поток работы агента: + +1. **Загрузите руководство:** `lizard skills get core --json` → прочитайте `content`. +2. **Проверьте авторизацию оптимистически:** выполните задачу пользователя; при коде выхода `2` запустите `lizard login`, передайте пользователю выведенный URL, затем повторите попытку. +3. **Определите контекст перед мутацией:** `lizard status` (связка cwd) и `lizard ps --json` (сервисы). +4. **Действуйте** с помощью руководства — `add`, `up`, `secrets`, `domain` и т.д., всегда с `--json`. + +Если бинарник `lizard` отсутствует, сначала установите его: + +```bash +npm install -g @lizard-build/cli +``` + + + +## Соглашения, которым должны следовать агенты + +- **Всегда передавайте `--json`** при неинтерактивных вызовах. +- **Подтверждайте деструктивные действия** (удаление сервиса, удаление аддона, перезапись секрета на уровне проекта, перезагрузка продакшена) с пользователем — встроенные подсказки CLI срабатывают только при наличии TTY. +- **Ограничивайте область действия секретов потребляющим сервисом** по умолчанию; резервируйте `--global` для явно публичных значений. См. [Переменные и секреты](/variables#scoping). +- **Не пишите Dockerfile без запроса** — lizardpack автоматически определяет большинство стеков. Сначала попробуйте задеплоить. См. [Конвейер сборки](/concepts/build-pipeline). +- **Не используйте `lizard up` для переключения git-базированного сервиса на загрузку** — используйте `service set` + `redeploy`. + + + +## Интеграции с редакторами + +Lizard Skill распространяется как публичный бутстрап, чтобы агенты в редакторах и ассистентах могли устанавливать и загружать его по требованию, а затем управлять тем же CLI, который описан во всей этой документации. CLI — единственный источник правды — отдельного API для агентов не существует. + +Это относится и к AI IDE: они пишут и тестируют приложение, но не хостят его. См. [развертывание приложения, созданного в Google Antigravity](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command), где весь деплой выполняется из двух промптов. + + + +## См. также + +- [`lizard skills`](/cli/skills) — полная справочная информация по командам. +- [JSON и автоматизация](/cli/json) — вывод `--json` и обнаружение схем. +- [Переменные и секреты](/variables#scoping) — соглашения об области действия секретов, которым должны следовать агенты. +- [Разверните ваше приложение из Claude Code](https://lizard.build/blog/deploy-from-claude-code#deploy-from-claude-code-in-3-steps) — тот же бутстрап, представленный как пошаговое руководство, с промптами, которые его управляют. + + + +## Хостинг собственного MCP-сервера + +Агент, использующий Lizard CLI, и приложение, предоставляющее MCP — это отдельные рабочие процессы. Команды CLI, описанные выше, не предоставляют MCP-транспорт. Чтобы развернуть собственный сервер с Streamable HTTP, следуйте [руководству по удаленному MCP](/guides/deploy-mcp-server). diff --git a/_locales/ru/cli/_meta.ts b/_locales/ru/cli/_meta.ts new file mode 100644 index 0000000..0b990bf --- /dev/null +++ b/_locales/ru/cli/_meta.ts @@ -0,0 +1,46 @@ +export default { + index: "Обзор", + json: "JSON и автоматизация", + '-- auth': { type: "separator", title: "Авторизация и аккаунт" }, + login: "login", + logout: "logout", + whoami: "whoami", + workspace: "workspace", + '-- projects': { type: "separator", title: "Проекты и привязка" }, + init: "init", + link: "link", + unlink: "unlink", + status: "status", + project: "project", + config: "config", + '-- create': { type: "separator", title: "Создание сервисов и аддонов" }, + add: "add", + '-- deploy': { type: "separator", title: "Деплой" }, + up: "up", + redeploy: "redeploy", + restart: "restart", + '-- svc': { type: "separator", title: "Конфигурация сервиса" }, + service: "service", + port: "port", + scale: "scale", + '-- secrets': { type: "separator", title: "Секреты" }, + secrets: "secrets", + '-- domains': { type: "separator", title: "Домены" }, + domain: "domain", + '-- observability': { type: "separator", title: "Логи, метрики и события" }, + logs: "logs", + metrics: "metrics", + events: "events", + ps: "ps", + '-- running': { type: "separator", title: "Выполнение команд" }, + run: "run", + ssh: "ssh", + '-- github': { type: "separator", title: "GitHub" }, + git: "git", + '-- misc': { type: "separator", title: "Разное" }, + regions: "regions", + open: "open", + docs: "docs", + upgrade: "upgrade", + skills: "skills", +}; diff --git a/_locales/ru/cli/add.mdx b/_locales/ru/cli/add.mdx new file mode 100644 index 0000000..d88a1f6 --- /dev/null +++ b/_locales/ru/cli/add.mdx @@ -0,0 +1,78 @@ +--- +description: "lizard add создает сервис из GitHub-репозитория, пустой сервис или управляемый аддон. Полный справочник флагов с рабочими примерами." +--- + +# lizard add + +Добавляет базу данных, сервис или репозиторий в проект. + + + +## Использование + +```bash +lizard add [types...] [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-r, --repo ` | Создать сервис из GitHub-репозитория | +| `-s, --service ` | Создать пустой сервис | +| `-a, --addon ` | Добавить управляемые аддоны (`postgres` / `redis` / `s3`) | +| `-n, --name ` | Имя, используемое в ссылках `${{name.KEY}}` | +| `-v, --variables ` | Задать переменную окружения (можно повторять) | +| `--region ` | Регион для provisioning | +| `--no-deploy` | Привязать репозиторий, но пропустить первую сборку | +| `--list` | Показать доступные типы баз данных | + + + +## Примеры + + + +### Создать сервис из GitHub-репозитория + +```bash +lizard add -r your-org/your-app +``` + +Это создает `github`-source-сервис, клонирует репозиторий, автоматически определяет стек, собирает его и возвращает рабочий URL. + + + +### Подготовить аддоны + +```bash +lizard add postgres # one addon +lizard add postgres redis s3 # several at once +lizard add --list # show available types +``` + + + +### Создать пустой сервис + +```bash +lizard add -s worker +``` + + + +### Назвать сервис и задать переменные + +```bash +lizard add -r your-org/monorepo -n api +``` + + + +## См. также + +- [Развертывание из GitHub](/deploy/github) — подключение репозиториев, приватный доступ и авто-переразвертывание при push +- [Управляемые аддоны](/addons) — создание, именование и использование postgres/redis/s3 +- [lizard up](/cli/up) — загрузка и развертывание текущей директории вместо привязки репозитория diff --git a/_locales/ru/cli/config.mdx b/_locales/ru/cli/config.mdx new file mode 100644 index 0000000..4eac675 --- /dev/null +++ b/_locales/ru/cli/config.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard config apply отправляет файл lizard-config.json в ваш проект, с флагом --dry-run для предварительного просмотра изменений." +--- + +# lizard config + +Применить файл `lizard-config.json` к проекту. + + + +## Использование + +```bash +lizard config apply [flags] +``` + + + +## Подкоманды + +### `lizard config apply` + +Применить файл `lizard-config.json` к проекту. + +| Флаг | Описание | +|------|-------------| +| `-f, --file ` | Файл конфигурации (по умолчанию `lizard-config.json`) | +| `--dry-run` | Показать, что изменится, без применения | + + + +## Примеры + + + +### Применить файл конфигурации по умолчанию + +```bash +lizard config apply +``` + + + +### Применить файл конфигурации по пользовательскому пути + +```bash +lizard config apply -f ./configs/prod.json +``` + + + +### Предварительный просмотр изменений без применения + +```bash +lizard config apply --dry-run +``` + + + +## См. также + +- [lizard service](/cli/service) — управление отдельными сервисами +- [Architecture](/concepts/architecture) — как связаны рабочие области, проекты и сервисы diff --git a/_locales/ru/cli/docs.mdx b/_locales/ru/cli/docs.mdx new file mode 100644 index 0000000..22694d0 --- /dev/null +++ b/_locales/ru/cli/docs.mdx @@ -0,0 +1,33 @@ +--- +description: "lizard docs открывает документацию Lizard в браузере по умолчанию прямо из терминала. Использование и примеры." +--- + +# lizard docs + +Открывает документацию в браузере. + + + +## Использование + +```bash +lizard docs +``` + + + +## Примеры + + + +### Открыть сайт документации + +```bash +lizard docs +``` + + + +## См. также + +- [Справочник CLI](/cli) — установка, глобальные флаги и коды выхода diff --git a/_locales/ru/cli/domain.mdx b/_locales/ru/cli/domain.mdx new file mode 100644 index 0000000..37196fb --- /dev/null +++ b/_locales/ru/cli/domain.mdx @@ -0,0 +1,104 @@ +--- +description: "lizard domain показывает домен сервиса, создаёт поддомен onlizard.com или привязывает и проверяет пользовательское имя хоста с автоматическим TLS." +--- + +# lizard domain + +Показывает текущий домен или привязывает пользовательский. + + + +## Использование + +```bash +lizard domain [hostname] [flags] +``` + +Имя хоста — позиционный аргумент, отдельного `add` подкоманды нет. Запуск `lizard domain` без аргументов показывает текущий домен сервиса. + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-s, --service ` | Сервис | +| `--port ` | Порт для публикации | + + + +## Подкоманды + +### `lizard domain generate` + +Создаёт новый поддомен `*.onlizard.com`. + +### `lizard domain verify ` + +Проверяет TXT-запись и активирует домен. TLS выпускается автоматически. + +### `lizard domain delete ` + +Удаляет домен (алиас `rm`). + +| Флаг | Описание | +|------|-------------| +| `-y, --yes` | Пропустить подтверждение | + + + +## Примеры + + + +### Показать текущий домен + +```bash +lizard domain +``` + + + +### Создать поддомен + +```bash +lizard domain generate +``` + + + +### Привязать пользовательский домен + +```bash +lizard domain app.example.com --service web +``` + +Lizard возвращает DNS-записи для создания (`CNAME` для имени хоста и `TXT` для проверки). Добавьте их у вашего DNS-провайдера, затем выполните проверку: + +```bash +lizard domain verify app.example.com +``` + + + +### Привязать домен к конкретному порту + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +### Удалить домен + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes +``` + + + +## См. также + +- [Networking](/networking) — сгенерированные домены, TLS и рабочие сервисы +- [Развернуть в регионах](/deploy/regions) — выбор региона для сервисов diff --git a/_locales/ru/cli/events.mdx b/_locales/ru/cli/events.mdx new file mode 100644 index 0000000..170fdc9 --- /dev/null +++ b/_locales/ru/cli/events.mdx @@ -0,0 +1,60 @@ +--- +description: "lizard events выводит историю развёртываний сервиса и текущий статус реплик, с флагами для ограничения записей или выбора конкретного сервиса." +--- + +# lizard events + +Показать историю развёртываний и статус реплик. + + + +## Использование + +```bash +lizard events [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-n, --limit ` | Количество записей для показа (по умолчанию 10) | +| `-s, --service ` | Показать события для конкретного сервиса | + + + +## Примеры + + + +### Показать историю развёртываний и статус реплик + +```bash +lizard events +``` + + + +### Показать события для конкретного сервиса + +```bash +lizard events --service api +``` + + + +### Показать больше записей + +```bash +lizard events --limit 25 +``` + + + +## См. также + +- [Events & History](/observability/events) — что охватывает каждая запись и как это соотносится с представлением «Развёртывания» на панели +- [lizard ps](/cli/ps) — быстрый снимок статуса и URL всех сервисов +- [Развертывания](/concepts/deployments) — жизненный цикл развёртывания diff --git a/_locales/ru/cli/git.mdx b/_locales/ru/cli/git.mdx new file mode 100644 index 0000000..e694470 --- /dev/null +++ b/_locales/ru/cli/git.mdx @@ -0,0 +1,80 @@ +--- +description: "lizard git подключает GitHub App, показывает статус репозитория и переключает сервис на другую ветку с повторным деплоем." +--- + +# lizard git + +Управление подключением GitHub для связанного проекта и его сервисов. + + + +## Использование + +```bash +lizard git connect +lizard git status +lizard git checkout [flags] +``` + + + +## Подкоманды + +### `lizard git connect` + +Подключить GitHub App для доступа к приватным репозиториям. + +### `lizard git status` + +Показать подключение GitHub и статус репозитория. + +### `lizard git checkout ` + +Переключить сервис на другую ветку и выполнить повторный деплой. + +| Флаг | Описание | +|------|-------------| +| `--detach` | Пропустить стриминг логов | + + + +## Примеры + + + +### Подключить GitHub App + +```bash +lizard git connect +``` + + + +### Проверить подключение и статус репозитория + +```bash +lizard git status +``` + + + +### Переключить сервис на другую ветку + +```bash +lizard git checkout api staging +``` + + + +### Переключить ветки без стриминга логов + +```bash +lizard git checkout api staging --detach +``` + + + +## См. также + +- [Деплой из GitHub](/deploy/github) — подключение репозитория, авто-деплой при пуше и настройка монорепо +- [lizard add](/cli/add) — создать сервис из репозитория GitHub diff --git a/_locales/ru/cli/index.mdx b/_locales/ru/cli/index.mdx new file mode 100644 index 0000000..9428eba --- /dev/null +++ b/_locales/ru/cli/index.mdx @@ -0,0 +1,88 @@ +--- +description: "Установите и обновите Lizard CLI, выполните аутентификацию, а также изучите глобальные флаги, коды выхода и автоматическое обнаружение схемы для каждой команды." +--- + + + +# Справочник по CLI + +`lizard` CLI — это основной интерфейс платформы. Эта страница охватывает установку, глобальные флаги, коды выхода и автоматическое обнаружение. У каждой команды есть собственная справочная страница в боковой панели — см. [`lizard up`](/cli/up), [`lizard service`](/cli/service), [`lizard secrets`](/cli/secrets) и остальные. + +> Справочник сгенерирован для CLI **v0.3.62**. Выполните `lizard --help --json` для получения точной схемы, соответствующей версии, для любой команды. + + + +## Установка и обновление + +```bash +npm install -g @lizard-build/cli +lizard --version +lizard upgrade # update to the latest version +lizard upgrade --check # check without installing +``` + +Всегда используйте глобально установленный бинарный файл `lizard` — **не** `npx`. См. [Быстрый старт](/getting-started#1-install-the-cli) для исправления ошибок доступа. + + + +## Аутентификация + +```bash +lizard login # browser OAuth +lizard login --token lzd_xxx # token auth +lizard logout +lizard whoami # current user, workspace, linked project +``` + +В CI задайте `LIZARD_TOKEN` в переменных окружения вместо запуска `login`. + + + +## Глобальные флаги + +| Флаг | Описание | +|------|-------------| +| `-V, --version` | Вывести версию CLI | +| `--json` | Машинно-читаемый вывод. Комбинируйте с `--help`, чтобы выгрузить схему команды | + +Большинство команд также принимают `-p, --project`, `-s, --service` и `-w, --workspace` для обращения к конкретному ресурсу вместо связанного. + + + +## Коды выхода + +| Код | Значение | Что делать | +|------|---------|------------| +| `0` | успех | продолжать | +| `1` | общая ошибка | прочитать сообщение | +| `2` | аутентификация (401/403) | выполните `lizard login` | +| `3` | не найдено (404) | проверьте имя с помощью `lizard ps` / `lizard project list` | +| `4` | таймаут (408/504) | повторите попытку | +| `5` | отменено пользователем | остановиться | + + + +## Автоматическое обнаружение + +CLI является самодокументирующимся. Чтобы увидеть полное дерево команд, глобальные флаги и коды выхода: + +```bash +lizard --help --json +``` + +Для точных аргументов и опций любой команды или подкоманды: + +```bash +lizard --help --json +lizard --help --json # e.g. lizard service set --help --json +``` + +Это всегда отражает вашу установленную версию — используйте это вместо угадывания формата флагов. Так агент узнаёт CLI без обучения на нём: см. [развёртывание из Claude Code](https://lizard.build/blog/deploy-from-claude-code). + + + +## Конфигурация и состояние + +- CLI хранит аутентификацию и ссылку на проект текущей директории в `~/.lizard/config.json`. +- `lizard status` показывает ссылку на рабочую область/проект/сервис текущей директории (аутентификация не требуется). +- `lizard config apply` применяет файл `lizard-config.json` к проекту (используйте `--dry-run` для предварительного просмотра). diff --git a/_locales/ru/cli/init.mdx b/_locales/ru/cli/init.mdx new file mode 100644 index 0000000..618f8d7 --- /dev/null +++ b/_locales/ru/cli/init.mdx @@ -0,0 +1,66 @@ +--- +description: "lizard init создаёт или выбирает проект и связывает его с текущей директорией, включая явную форму, необходимую в CI." +--- + +# lizard init + +Создаёт или выбирает проект и связывает его с текущей директорией. + + + +## Использование + +```bash +lizard init [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-n, --name ` | Имя проекта (создастся, если отсутствует) | +| `-w, --workspace ` | ID, слаг или имя рабочей области | +| `--force` | Пересвязать даже если уже связано | + + + +## Примеры + + + +### Интерактивно связать текущую директорию + +```bash +lizard init +``` + + + +### Явно связать в CI + +`lizard up` запустит `init` за вас в TTY, но в не-TTY среде (CI) выдаст ошибку вместо того, чтобы молча создать проект. Свяжите явно сначала: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +### Пересвязать директорию, которая уже связана + +```bash +lizard init --name my-project --force +``` + + + +## См. также + +- [lizard link](/cli/link) — связать текущую директорию с существующим проектом вместо создания нового +- [lizard status](/cli/status) — показать связанную рабочую область, проект и сервис для текущей директории +- [lizard up](/cli/up) — загрузить и развернуть текущую директорию +- [Основные понятия](/concepts/architecture) — проекты, сервисы и конвейер сборки diff --git a/_locales/ru/cli/json.mdx b/_locales/ru/cli/json.mdx new file mode 100644 index 0000000..6b031c3 --- /dev/null +++ b/_locales/ru/cli/json.mdx @@ -0,0 +1,90 @@ +--- +description: "Скриптируйте Lizard CLI: --json для каждой команды, построчные события для стриминговых сборок, обнаружение схемы и токеновая авторизация в CI." +--- + + + +# JSON и автоматизация + +CLI создан для скриптинга. Передавайте `--json` для машиночитаемого вывода, управляйте из CI с помощью токена и обнаруживайте схему любой команды в рантайме. + +Другой читатель этого вывода — ИИ-агент для кодинга — [деплой из Claude Code](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) показывает, что он делает с JSON неудачной сборки. + + + +## `--json` везде + +Добавляйте `--json` к любой команде для структурированного вывода. CLI также автоматически переключается на JSON, когда stdout не является TTY. + +```bash +lizard ps --json +lizard secrets list --json +lizard metrics --json +``` + + + +### Команды со стримингом + +Для стриминговых команд (`lizard up` без `--detach`) `--json` выдаёт **один JSON-объект на строку**: + +```json +{ "event": "log", "line": "Step 1/8 : FROM node:20" } +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "running", "url": "https://app.onlizard.com" } +``` + +Поток завершается `done`, или `error` / `failed`. `lizard up` дополнительно выдаёт финальное событие `deployed` / `failed` / `deploying` с `status` и `url` (которые могут быть `null`). + + + +### `logs --json` — это снимок, а не поток + +`lizard logs --json` возвращает **последние 200 строк** (переопределяется через `--tail N`, максимум 1000) и завершается. Не ждите от него дополнительного вывода. Для конкретного инцидента используйте `--restart latest` или `--restart `. + + + +## Обнаружение схемы + +Выведите точные аргументы, опции и коды выхода любой команды: + +```bash +lizard --help --json # whole tree + global flags + exit codes +lizard service set --help --json # one command +``` + +Формат ответа — `{ cli, version, command: { arguments, options, subcommands }, globalOptions, exitCodes }`. Поскольку он генерируется из вашего установленного бинарника, он всегда соответствует вашей версии — лучше полагаться на него, чем хардкодить флаги. + + + +## CI / работа без интерфейса + +Аутентифицируйтесь токеном и явно укажите проект (безголовый `up` не создаст проект автоматически): + +```bash +# Set LIZARD_TOKEN through your CI secret store. +lizard init --name my-project +lizard up --ci --service api --detach +``` + +Проверяйте коды выхода для ветвления пайплайна: + +| Код | Значение | +|------|---------| +| `0` | успех | +| `1` | общая ошибка | +| `2` | авторизация — токен отсутствует / просрочен | +| `3` | не найдено | +| `4` | таймаут | +| `5` | отменено | + +```bash +if lizard redeploy --service api --json; then + echo "Deploy succeeded" +else + status=$? + echo "Deploy failed with code $status" >&2 + lizard logs --build --json || true + exit "$status" +fi +``` diff --git a/_locales/ru/cli/link.mdx b/_locales/ru/cli/link.mdx new file mode 100644 index 0000000..a77878a --- /dev/null +++ b/_locales/ru/cli/link.mdx @@ -0,0 +1,62 @@ +--- +description: "lizard link связывает текущую директорию с существующим проектом, а также при необходимости с конкретным сервисом или рабочей областью." +--- + +# lizard link + +Связывает текущую директорию с существующим проектом (и при необходимости с сервисом). + + + +## Использование + +```bash +lizard link [service] [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-p, --project ` | Имя проекта, слаг или ID | +| `-s, --service ` | Сервис для связывания | +| `-w, --workspace ` | Рабочая область | + + + +## Примеры + + + +### Связывание с существующим проектом + +```bash +lizard link --project my-project +``` + + + +### Связывание с проектом и конкретным сервисом + +```bash +lizard link my-service --project my-project +``` + + + +### Связывание в конкретной рабочей области + +```bash +lizard link --project my-project --workspace my-workspace +``` + + + +## См. также + +- [lizard init](/cli/init) — создать или выбрать проект и связать его за один шаг +- [lizard unlink](/cli/unlink) — удалить связь из текущей директории +- [lizard status](/cli/status) — показать связанную рабочую область, проект и сервис +- [Архитектура: Проект](/concepts/architecture) — как работает связь директории с проектом diff --git a/_locales/ru/cli/login.mdx b/_locales/ru/cli/login.mdx new file mode 100644 index 0000000..d8fe34a --- /dev/null +++ b/_locales/ru/cli/login.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard login выполняет аутентификацию через браузер или API-токен, а также как аутентифицироваться неинтерактивно в CI с помощью LIZARD_TOKEN." +--- + +# lizard login + +Выполните вход в Lizard. + + + +## Использование + +```bash +lizard login [flags] +``` + +По умолчанию открывается браузер для аутентификации через OAuth, затем управление возвращается в терминал после подтверждения. + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `--token ` | Аутентификация с помощью API-токена | + + + +## Примеры + + + +### Вход через браузер + +```bash +lizard login +``` + + + +### Вход с токеном + +```bash +lizard login --token lzd_xxx +``` + + + +### Неинтерактивный вход в CI + +В CI или других неинтерактивных средах задайте `LIZARD_TOKEN` в переменных окружения вместо запуска `login`: + +```bash +export LIZARD_TOKEN=lzd_xxx +``` + + + +## См. также + +- [lizard logout](/cli/logout) — выход из системы +- [lizard whoami](/cli/whoami) — показать текущего пользователя, активное рабочее пространство и связанный проект +- [Справочник CLI](/cli) — глобальные флаги, коды выхода и обзор аутентификации diff --git a/_locales/ru/cli/logout.mdx b/_locales/ru/cli/logout.mdx new file mode 100644 index 0000000..7af3620 --- /dev/null +++ b/_locales/ru/cli/logout.mdx @@ -0,0 +1,22 @@ +--- +description: "lizard logout выходит из Lizard CLI и удаляет сохранённые на этом компьютере учётные данные. Чтобы войти снова, выполните lizard login." +--- + +# lizard logout + +Выйти. + + + +## Использование + +```bash +lizard logout +``` + + + +## См. также + +- [lizard login](/cli/login) — аутентификация в Lizard +- [lizard whoami](/cli/whoami) — показать текущего пользователя, активное рабочее пространство и связанный проект diff --git a/_locales/ru/cli/logs.mdx b/_locales/ru/cli/logs.mdx new file mode 100644 index 0000000..f1d3100 --- /dev/null +++ b/_locales/ru/cli/logs.mdx @@ -0,0 +1,93 @@ +--- +description: "lizard logs выводит логи выполнения сервиса, логи сборки, логи перезапусков и отфильтрованную историю с помощью флагов --build, --tail и --level." +--- + +# lizard logs + +Выводит логи выполнения сервиса — последние 200 строк с последующим живым просмотром. + + + +## Использование + +```bash +lizard logs [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `--build` | Показать логи сборки | +| `--tail ` | Последние N строк (максимум 1000) | +| `-l, --level ` | Фильтр по уровню | +| `--restarts [n]` | Список последних перезапусков | +| `--restart ` | Логи вокруг конкретного перезапуска (`latest` для самого последнего) | +| `-s, --service ` | Сервис | + +При `--json` `lizard logs` не является стримом — возвращает последние 200 строк (можно переопределить `--tail N`, максимум 1000) и завершается. Используйте для снапшотов и скриптов; живой стрим доступен только без `--json`. + + + +## Примеры + + + +### Просмотр логов выполнения в реальном времени + +```bash +lizard logs +``` + + + +### Просмотр логов конкретного сервиса в реальном времени + +```bash +lizard logs --service api +``` + + + +### Получить больше истории + +```bash +lizard logs --tail 1000 +``` + + + +### Фильтр по уровню лога + +```bash +lizard logs --level error +``` + + + +### Проверка последней сборки + +```bash +lizard logs --build +``` + + + +### Исследовать сбой или перезапуск + +```bash +lizard logs --restarts +lizard logs --restart latest +lizard logs --restart +``` + + + +## См. также + +- [Логи](/observability/logs) — поведение логов выполнения, сборки и перезапусков, а также постраничная навигация по истории с `lizard service logs` +- [Incomplete Dockerfile](/deploy/troubleshooting/incomplete-dockerfile) — диагностика неудачной сборки из `lizard logs --build` +- [lizard events](/cli/events) — история деплоев и статус реплик +- [Развернуть из Claude Code](https://lizard.build/blog/deploy-from-claude-code#how-lizard-handles-claude-code-deployment) — цикл чтения логов, исправления и повторного деплоя, который агент выполняет при неудачной сборке diff --git a/_locales/ru/cli/metrics.mdx b/_locales/ru/cli/metrics.mdx new file mode 100644 index 0000000..8acae0d --- /dev/null +++ b/_locales/ru/cli/metrics.mdx @@ -0,0 +1,68 @@ +--- +description: "Команда lizard metrics показывает загрузку CPU, память, сеть и диск для сервиса, с живым режимом --watch и опциональными данными о стоимости." +--- + +# lizard metrics + +Показывает CPU / память / сеть / диск и стоимость. + + + +## Использование + +```bash +lizard metrics [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-r, --range ` | Временное окно | +| `-w, --watch` | Живое обновление | +| `--cost` | Включить стоимость | + + + +## Примеры + + + +### Просмотр метрик для текущего сервиса + +```bash +lizard metrics +``` + + + +### Просмотр метрик для конкретного сервиса + +```bash +lizard metrics --service api +``` + + + +### Живой просмотр метрик + +```bash +lizard metrics --watch +``` + + + +### С включением стоимости + +```bash +lizard metrics --cost +``` + + + +## См. также + +- [Метрики и стоимость](/observability/metrics) — представления дашборда и действия на основе использования +- [Масштабирование](/deploy/scaling) — изменение размера или добавление реплик в ответ на метрики diff --git a/_locales/ru/cli/open.mdx b/_locales/ru/cli/open.mdx new file mode 100644 index 0000000..4d3e66a --- /dev/null +++ b/_locales/ru/cli/open.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard open открывает панель управления текущего проекта в браузере, визуальную версию CLI." +--- + +# lizard open + +Открыть проект в браузере. + + + +## Использование + +```bash +lizard open +``` + + + +## Примеры + + + +### Открыть панель управления текущего проекта + +```bash +lizard open +``` + + + +## См. также + +- [Панель управления](/dashboard) — визуальная версия CLI, которую открывает эта команда +- [Развернуть приложение Antigravity в продакшн](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command) — наблюдайте, как агент разворачивает приложение в продакшн без необходимости вводить команды вручную diff --git a/_locales/ru/cli/port.mdx b/_locales/ru/cli/port.mdx new file mode 100644 index 0000000..8643429 --- /dev/null +++ b/_locales/ru/cli/port.mdx @@ -0,0 +1,59 @@ +--- +description: "lizard port показывает или меняет контейнерный порт сервиса. Установка в 0 переводит сервис в рабочий режим без входящей маршрутизации." +--- + +# lizard port + +Показать или изменить контейнерный порт для сервиса. Без аргументов выводит текущий порт (`worker mode`, когда он `0`). + + + +## Использование + +```bash +lizard port [value] [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-s, --service ` | Сервис для управления | + + + +## Примеры + + + +### Показать текущий порт + +```bash +lizard port +``` + + + +### Установить порт для конкретного сервиса + +```bash +lizard port 0 -s worker +``` + + + +### Проверить порт рабочего сервиса + +```bash +lizard port --service worker +``` + + + +## См. также + +- [Фоновые рабочие процессы](/deploy/workers) — установите порт в `0`, чтобы запустить сервис без входящей маршрутизации +- [lizard service](/cli/service) — управляйте остальной конфигурацией сервиса +- [Что нужно Python-приложению от хостинга](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) — почему `gunicorn` или `uvicorn` процесс должен привязываться к `$PORT` на `0.0.0.0` diff --git a/_locales/ru/cli/project.mdx b/_locales/ru/cli/project.mdx new file mode 100644 index 0000000..55f0798 --- /dev/null +++ b/_locales/ru/cli/project.mdx @@ -0,0 +1,56 @@ +--- +description: "lizard project выводит список проектов в рабочей области или создаёт новый, с примерами для обеих подкоманд." +--- + +# lizard project + +Вывод списка или создание проектов в рабочей области. + + + +## Использование + +```bash +lizard project list +lizard project create +``` + + + +## Подкоманды + +### `lizard project list` + +Выводит все проекты в рабочей области. + +### `lizard project create` + +Создаёт новый проект. + + + +## Примеры + + + +### Вывод списка проектов в рабочей области + +```bash +lizard project list +``` + + + +### Создание нового проекта + +```bash +lizard project create +``` + + + +## См. также + +- [lizard init](/cli/init) — создать или выбрать проект и связать его с текущей директорией +- [lizard link](/cli/link) — связать текущую директорию с существующим проектом +- [Architecture](/concepts/architecture) — как проекты связаны с рабочими областями и сервисами diff --git a/_locales/ru/cli/ps.mdx b/_locales/ru/cli/ps.mdx new file mode 100644 index 0000000..c0f319a --- /dev/null +++ b/_locales/ru/cli/ps.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard ps выводит список всех сервисов в связанном проекте с их статусом и рабочим URL — быстрый срез того, что сейчас запущено." +--- + +# lizard ps + +Выводит список всех сервисов в проекте с их статусом и URL. + + + +## Использование + +```bash +lizard ps +``` + + + +## Примеры + + + +### Список сервисов в связанном проекте + +```bash +lizard ps +``` + + + +## См. также + +- [lizard status](/cli/status) — показать связанные рабочую область, проект и сервис для текущей директории +- [lizard events](/cli/events) — показать историю деплоев и статус реплик diff --git a/_locales/ru/cli/redeploy.mdx b/_locales/ru/cli/redeploy.mdx new file mode 100644 index 0000000..68b120f --- /dev/null +++ b/_locales/ru/cli/redeploy.mdx @@ -0,0 +1,69 @@ +--- +description: "lizard redeploy запускает новую сборку из последнего коммита или загрузки с текущими переменными, выводя логи в потоке, если не указан флаг --detach." +--- + +# lizard redeploy + +Запустите новую сборку (последний коммит / последняя загрузка) с текущими переменными. + + + +## Использование + +```bash +lizard redeploy [nameOrId] [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|--------------| +| `-s, --service ` | Сервис | +| `--detach` | Вернуться после принятия сборки | +| `--wait` | Ждать готовности сборки и развёртывания; работает с `--json` | +| `--timeout ` | Бюджет ожидания готовности после сборки; по умолчанию `120` | +| `--json` | Вернуть JSON для скриптов | + + + +## Примеры + + + +### Пересобрать и переразвернуть сервис + +```bash +lizard redeploy --service api +``` + + + +### Переразвернуть без потоковой передачи логов + +```bash +lizard redeploy --service api --detach +``` + + + +### Ожидание в скрипте + +Требуется CLI 0.3.94 или новее. Используйте 0.3.95 или новее для работников без HTTP. + +```bash +lizard --json redeploy --service api --wait --timeout 120 +``` + +Без `--wait` режим JSON возвращает управление после принятия запроса на сборку. С `--wait` CLI отслеживает эту сборку, а затем ждёт готовности развёртывания. JSON-результат включает `buildId`, `ok` и `status`. Ошибка сборки, проваленная проверка готовности или таймаут возвращают ненулевой код выхода. + +Таймаут применяется к готовности после завершения сборки; он не ограничивает длительность сборки и не отменяет развёртывание. Работники с `containerPort=0` используют статус готовности от бэкенда без HTTP-проверки. После успешного выполнения команды проверьте эндпоинт приложения или сохранённые данные, если ваш процесс требует проверки поведения приложения. + + + +## См. также + +- [lizard restart](/cli/restart) — последовательный перезапуск текущей сборки, без пересборки +- [lizard up](/cli/up) — загрузить текущую директорию и развернуть её +- [Развёртывания](/concepts/deployments) — как работают деплои, перезапуски и пересборки diff --git a/_locales/ru/cli/regions.mdx b/_locales/ru/cli/regions.mdx new file mode 100644 index 0000000..2d91a8a --- /dev/null +++ b/_locales/ru/cli/regions.mdx @@ -0,0 +1,64 @@ +--- +description: "lizard regions выводит список регионов, доступных вашему аккаунту, и показывает, как передавать --region при создании сервиса или аддона." +--- + +# lizard regions + +Выводит список доступных регионов. + + + +## Использование + +```bash +lizard regions [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `--json` | Вывод в формате JSON | + + + +## Примеры + + + +### Список доступных регионов + +```bash +lizard regions +``` + + + +### Список регионов в формате JSON + +```bash +lizard regions --json +``` + + + +### Выбор региона при создании сервиса или аддона + +Передайте `--region ` в `lizard add` или `lizard up`: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +Если вы не укажете регион, платформа использует регион проекта по умолчанию. + + + +## См. также + +- [Регионы](/deploy/regions) — выбор региона, совместное размещение и генерируемые домены +- [`lizard add`](/cli/add) — добавление сервиса, репозитория или аддона с помощью `--region` diff --git a/_locales/ru/cli/restart.mdx b/_locales/ru/cli/restart.mdx new file mode 100644 index 0000000..386385b --- /dev/null +++ b/_locales/ru/cli/restart.mdx @@ -0,0 +1,75 @@ +--- +description: "lizard restart выполняет перезапуск текущей сборки сервиса без пересборки, что полезно для восстановления после сбоя." +--- + +# lizard restart + +Постепенный перезапуск текущей сборки — без пересборки. + + + +## Использование + +```bash +lizard restart [nameOrId] [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|--------------| +| `-s, --service ` | Сервис | +| `--detach` | Вернуться после принятия перезапуска | +| `--wait` | Ждать готовности новой попытки перезапуска; работает с `--json` | +| `--timeout ` | Бюджет ожидания готовности с `--wait`; по умолчанию `120` | +| `--json` | Вернуть JSON для скриптов | + + + +## Примеры + + + +### Перезапустить сервис + +```bash +lizard restart --service api +``` + + + +### Перезапуск без потоковой передачи логов + +```bash +lizard restart --service api --detach +``` + + + +### Подождать перед запуском следующей проверки + +Требуется CLI 0.3.94 или новее. Используйте 0.3.95 или новее для рабочих процессов без HTTP. + +```bash +lizard --json restart --service api --wait --timeout 120 +``` + +Без `--wait` JSON-режим возвращается после принятия перезапуска. С `--wait` результат включает `ok`, `status`, `attemptId` и `waitedMs`. CLI ждёт новую попытку перезапуска, поэтому неизменный статус от до запроса не считается успехом. Неудачное ожидание или таймаут возвращают ненулевой код выхода. + +Для HTTP-сервисов CLI также проверяет домен сервиса дважды. Рабочие процессы с `containerPort=0` используют статус готовности из бэкенда и не требуют HTTP-слушателя, даже когда у них есть сгенерированный домен. + +```bash +lizard --json restart --service worker --wait --timeout 60 +``` + +Таймаут применяется к ожиданию готовности после запроса на перезапуск. Он не отменяет перезапуск, а сетевые вызовы могут сделать общее время выполнения команды дольше. Проверьте данные приложения или эндпоинт здоровья после команды, когда вашему рабочему процессу требуется больше, чем готовность процесса. + + + +## См. также + +- [lizard redeploy](/cli/redeploy) — запустить свежую сборку вместо перезапуска текущей +- [lizard logs](/cli/logs) — просмотреть логи вокруг перезапуска с `--restart latest` или `--restart ` +- [Развёртывания](/concepts/deployments) — перезапуски против повторных развёртываний и восстановление после сбоя diff --git a/_locales/ru/cli/run.mdx b/_locales/ru/cli/run.mdx new file mode 100644 index 0000000..caea702 --- /dev/null +++ b/_locales/ru/cli/run.mdx @@ -0,0 +1,63 @@ +--- +description: "lizard run выполняет команду на вашем компьютере с внедрением секретов проекта и сервиса. Включает информацию о том, когда использовать ssh вместо этого." +--- + +# lizard run + +Запускает команду локально с внедрением секретов проекта и сервиса. + +## run vs. ssh + +Две команды позволяют выполнять команды в контексте сервиса. Они выполняются в разных местах — важно понимать, какая вам нужна. + +| Команда | Где выполняется | Для чего нужна | +|---------|----------------|----------------| +| `lizard run` | Локально, с внедрением секретов проекта и сервиса | Миграции, скрипты наполнения базы, локальные инструменты, требующие продакшн-конфигурацию | +| `lizard ssh` | Внутри запущенного контейнера сервиса | Инспекция живого контейнера, разовые удалённые команды, отладка | + +`lizard run` показывает вашу локальную копию окружения с внедрёнными секретами, которая обычно совпадает с тем, что видит запущенное приложение — но `lizard ssh` является авторитетным источником для живого контейнера. Чтобы узнать, что на самом деле видит запущенное приложение, используйте `lizard ssh`. + + + +## Использование + +```bash +lizard run [flags] -- +``` + + + +## Флаги + +| Флаг | Описание | +|------|----------| +| `-s, --service ` | Сервис, чьё окружение внедрять | +| `--no-service` | Не внедрять окружение сервиса | + + + +## Примеры + + + +### Запуск миграции с внедрением секретов сервиса + +```bash +lizard run --service api -- node scripts/migrate.js +``` + + + +### Вывод внедрённой переменной окружения + +```bash +lizard run --service api -- printenv DATABASE_URL +``` + + + +## См. также + +- [lizard ssh](/cli/ssh) — выполнить команду внутри запущенного контейнера сервиса вместо локального запуска +- [Переменные](/variables) — как определяются и ссылаются переменные проекта и сервиса +- [Хостинг Python-приложений](https://lizard.build/blog/python-app-hosting) — запуск `manage.py` и других фреймворковых инструментов с развёрнутой базой данных diff --git a/_locales/ru/cli/scale.mdx b/_locales/ru/cli/scale.mdx new file mode 100644 index 0000000..473cb1f --- /dev/null +++ b/_locales/ru/cli/scale.mdx @@ -0,0 +1,67 @@ +--- +description: "lizard scale изменяет количество реплик сервиса, CPU и память, а также увеличивает хранилище аддона. Допустимые значения и примеры для каждого флага." +--- + +# lizard scale + +Масштабирование сервиса (реплики / CPU / память / хранилище). + + + +## Использование + +```bash +lizard scale [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `--replicas ` | Реплики `1`–`10` (приложения) | +| `--cpu ` | `1`, `2`, `3` или `4` | +| `--memory ` | `128`–`8192` МБ | +| `--storage ` | Размер тома аддона, только увеличение | + + + +## Примеры + + + +### Горизонтальное масштабирование реплик + +```bash +lizard scale --service api --replicas 5 +``` + +Каждая реплика — это отдельный под за балансировщиком нагрузки. Убедитесь, что ваше приложение stateless, чтобы реплики были взаимозаменяемы. + + + +### Вертикальное масштабирование CPU и памяти + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +### Увеличение хранилища аддона + +```bash +lizard scale --service postgres --storage 8192 +``` + +Тома данных аддонов поддерживают только увеличение — вы можете расширить хранилище, но не уменьшить его. + + + +## См. также + +- [Масштабирование](/deploy/scaling) — горизонтальное и вертикальное масштабирование, увеличение хранилища аддонов +- [lizard metrics](/cli/metrics) — проверка CPU / памяти / сети / диска до и после масштабирования +- [lizard ps](/cli/ps) — проверка статуса реплик после изменения масштаба +- [Наблюдаемость → Metrics](/observability/metrics) — мониторинг ресурсов и затрат diff --git a/_locales/ru/cli/secrets.mdx b/_locales/ru/cli/secrets.mdx new file mode 100644 index 0000000..57cf05c --- /dev/null +++ b/_locales/ru/cli/secrets.mdx @@ -0,0 +1,100 @@ +--- +description: "lizard secrets устанавливает, выводит список, удаляет и импортирует переменные окружения на уровне сервиса или проекта, включая импорт dotenv из stdin." +--- + +# lizard secrets + +Управляйте секретами (переменными окружения) проекта или сервиса. + + + +## Использование + +```bash +lizard secrets [args] [flags] +``` + + + +## Подкоманды + +### `lizard secrets set ...` + +Устанавливает один или несколько секретов (вариадический). По умолчанию область — сервис; `--global` задаёт проект. + +| Флаг | Описание | +|------|-------------| +| `--global` | Область проекта | +| `-s, --service ` | Область сервиса | + +### `lizard secrets list` + +Выводит список секретов в области. + +| Флаг | Описание | +|------|-------------| +| `--show` | Показать значения | +| `--ref` | Показать ссылки | + +### `lizard secrets delete ...` + +Удаляет один или несколько секретов (вариадический). + +### `lizard secrets import` + +Импортирует dotenv-файл из stdin. + + + +## Примеры + + + +### Установка секретов на связанном сервисе + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + + + +### Установка секрета на уровне проекта + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +### Вывод списка секретов с раскрытием значений + +```bash +lizard secrets list +lizard secrets list --show +``` + + + +### Удаление секретов + +```bash +lizard secrets delete OLD_KEY ANOTHER_KEY +``` + + + +### Импорт dotenv-файла + +```bash +cat .env | lizard secrets import +``` + + + +## См. также + +- [Переменные & secrets](/variables) — области видимости, приоритет и поведение во время сборки и выполнения +- [Межсервисные ссылки](/variables/references) — чтение значений одного сервиса из другого +- [Устранение неполадок: секрет или ссылка на переменную не отображается](/variables/troubleshooting/reference-not-applied) +- [lizard run](/cli/run) — запуск команды локально с внедрением секретов проекта и сервиса diff --git a/_locales/ru/cli/service.mdx b/_locales/ru/cli/service.mdx new file mode 100644 index 0000000..0ce5555 --- /dev/null +++ b/_locales/ru/cli/service.mdx @@ -0,0 +1,95 @@ +--- +description: "Команда lizard service читает и редактирует настройки сборки, запуска, источника и переменных сервиса, а также обрабатывает переименование, удаление, логи и связывание." +--- + +# lizard service + +Управление конфигурацией, источником и жизненным циклом отдельного сервиса. + + + +## Использование + +```bash +lizard service set [flags] +lizard service show [flags] +lizard service rename +lizard service delete [flags] +lizard service logs +lizard service link +``` + + + +## Подкоманды + +### `lizard service set` + +Применяет изменения параметров сборки, запуска, источника, переменных или переименования к сервису. + +| Флаг | Описание | +|------|-------------| +| `--set =` | Установить поле (можно указывать несколько раз) | +| `-f, --file ` | JSON-файл конфигурации для применения | +| `--force` | Перезаписать даже при наличии удалённых изменений | + +Общие поля плоские и отображаются 1:1 в схему API: `sourceType`, `repoUrl`, `branch`, `rootDirectory`, `dockerfilePath`, `buildCommand`, `startCommand`, `preDeployCommand`, `watchPatterns`, `containerPort`, `name`. + +`service set` использует оптимистичную блокировку через `configRevision`. При `409` перечитайте конфигурацию с помощью `lizard service show`, приведите в соответствие и повторите попытку — или передайте `--force`. + +### `lizard service show` + +Показывает текущую конфигурацию сервиса в JSON. Используйте `-s`, чтобы ограничить вывод одним сервисом. + +### `lizard service rename` + +Переименовывает сервис или аддон. Ссылки на него (`${{name.KEY}}`) остаются стабильными. + +### `lizard service delete` + +Удаляет сервис. `-y, --yes` пропускает запрос подтверждения. + +### `lizard service logs` + +Выводит логи сервиса в потоке (см. также [lizard logs](/cli/logs)). + +### `lizard service link` + +Связывает сервис с текущей директорией. + + + +## Примеры + + + +### Обновление команд сборки и запуска сервиса + +```bash +lizard service set api --set branch=main --set buildCommand="npm run build" +``` + + + +### Просмотр полной конфигурации сервиса + +```bash +lizard service show -s api +``` + + + +### Удаление сервиса без запроса подтверждения + +```bash +lizard service delete -y +``` + + + +## См. также + +- [lizard port](/cli/port) — показать или изменить порт контейнера сервиса +- [lizard scale](/cli/scale) — масштабировать реплики, CPU, память или хранилище сервиса +- [Архитектура](/concepts/architecture) — как сервисы связаны с проектами и аддонами +- [Конвейер сборки](/concepts/build-pipeline) — как `buildCommand`, `startCommand` и настройки источника используются при сборке diff --git a/_locales/ru/cli/skills.mdx b/_locales/ru/cli/skills.mdx new file mode 100644 index 0000000..dae103b --- /dev/null +++ b/_locales/ru/cli/skills.mdx @@ -0,0 +1,61 @@ +--- +description: "lizard skills считывает руководства агентов, поставляемые с вашей версией CLI, поэтому ИИ-агент всегда получает инструкции, соответствующие бинарному файлу." +--- + +# lizard skills + +Чтение встроенных навыков агентов, поставляемых с данной версией CLI. + + + +## Использование + +```bash +lizard skills list +lizard skills get core +lizard skills path +``` + + + +## Подкоманды + +### `lizard skills list` + +Выводит список доступных встроенных навыков. + +### `lizard skills get core` + +Читает основное руководство — авторитетное руководство по использованию платформы, версионируемое вместе с CLI. Возвращает `{ name, frontmatter, content, … }`, где `content` — это полное руководство (конвейер сборки, приоритет переменных окружения, аддоны, обнаружение, коды выхода). + +### `lizard skills path` + +Показывает, где навыки хранятся на диске. + + + +## Примеры + + + +### Загрузка основного руководства агентом + +```bash +lizard skills get core --json +``` + + + +### Вывод списка доступных встроенных навыков + +```bash +lizard skills list +``` + + + +## См. также + +- [AI agents & MCP](/agents) — как агенты выполняют бутстрап с встроенным навыком и самодокументируемыми командами +- [JSON & automation](/cli/json) — формат вывода `--json`, используемый `lizard skills get core --json` +- [Развернуть из Claude Code](https://lizard.build/blog/deploy-from-claude-code) — установка навыка и передача деплоя агенту, сквозной процесс diff --git a/_locales/ru/cli/ssh.mdx b/_locales/ru/cli/ssh.mdx new file mode 100644 index 0000000..becf1d7 --- /dev/null +++ b/_locales/ru/cli/ssh.mdx @@ -0,0 +1,70 @@ +--- +description: "lizard ssh выполняет команду внутри работающего контейнера сервиса и возвращает его код выхода. Авторитетный способ узнать, что видит контейнер." +--- + +# lizard ssh + +Выполняет команду внутри контейнера работающего сервиса, передавая его вывод и возвращая удалённый код выхода. + +## run vs. ssh + +`lizard run` и `lizard ssh` выполняют команду в контексте сервиса, но запускают её в разных местах — понимайте, какой именно вам нужен. + +| Команда | Где запускается | Использовать для | +|---------|----------------|------------------| +| `lizard run` | **Локально**, с внедрёнными секретами проекта и сервиса | Миграции, сид-скрипты, локальные инструменты, требующие продакшн-конфигурации | +| `lizard ssh` | **Внутри работающего контейнера сервиса** | Инспекция живого контейнера, разовые удалённые команды, отладка | + +`lizard run` показывает вашу локальную внедрённую копию окружения, которая обычно совпадает с продакшн — но `lizard ssh` авторитетен для того, что видит живой контейнер на самом деле. + + + +## Использование + +```bash +lizard ssh --service -- +``` + + + +## Примеры + + + +### Инспектировать окружение, которое видит работающее приложение + +```bash +lizard ssh --service api -- env +``` + + + +### Посмотреть файлы в развёрнутом образе + +```bash +lizard ssh --service api -- ls -la /app +``` + + + +### Узнать ОС в контейнере + +```bash +lizard ssh --service api -- cat /etc/os-release +``` + + + +### Подтвердить, что секрет попал в живой контейнер + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## См. также + +- [lizard run](/cli/run) — запустить команду локально с внедрённым окружением сервиса +- [Переменные](/variables) — как секреты и ссылки попадают в сервис +- [Деплой из Claude Code](https://lizard.build/blog/deploy-from-claude-code#claude-code-deployment-compared-with-the-alternatives) — зачем агенту шелл в работающий контейнер и какие платформы его не дают diff --git a/_locales/ru/cli/status.mdx b/_locales/ru/cli/status.mdx new file mode 100644 index 0000000..56d7a32 --- /dev/null +++ b/_locales/ru/cli/status.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard status показывает, к какому рабочему пространству, проекту и сервису привязана текущая директория, прежде чем вы задеплоите не туда." +--- + +# lizard status + +Показывает связанное рабочее пространство, проект и сервис для текущей директории. + + + +## Использование + +```bash +lizard status +``` + + + +## Примеры + + + +### Проверить привязку текущей директории + +```bash +lizard status +``` + + + +## См. также + +- [lizard init](/cli/init) — создать или выбрать проект и привязать его к текущей директории +- [lizard link](/cli/link) — связать текущую директорию с существующим проектом +- [lizard whoami](/cli/whoami) — показать текущего пользователя, активное рабочее пространство и привязанный проект diff --git a/_locales/ru/cli/unlink.mdx b/_locales/ru/cli/unlink.mdx new file mode 100644 index 0000000..12b8f31 --- /dev/null +++ b/_locales/ru/cli/unlink.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard unlink удаляет связь между текущей директорией и любым проектом, сам проект остаётся без изменений." +--- + +# lizard unlink + +Отвязывает текущую директорию от любого проекта. + + + +## Использование + +```bash +lizard unlink +``` + + + +## Примеры + + + +### Отвязать текущую директорию + +```bash +lizard unlink +``` + + + +## См. также + +- [lizard link](/cli/link) — связать текущую директорию с проектом +- [lizard status](/cli/status) — проверить связанное рабочее пространство, проект и сервис diff --git a/_locales/ru/cli/up.mdx b/_locales/ru/cli/up.mdx new file mode 100644 index 0000000..1961759 --- /dev/null +++ b/_locales/ru/cli/up.mdx @@ -0,0 +1,88 @@ +--- +description: "lizard up упаковывает текущую директорию, собирает её на узлах сборки Lizard и возвращает живой URL. Флаги, поведение в CI и примеры." +--- + +# lizard up + +Загружает текущую директорию и выполняет деплой. + + + +## Использование + +```bash +lizard up [flags] +``` + +`up` упаковывает рабочую директорию в tarball, отправляет на узлы сборки и выполняет деплой. Принудительно включает `sourceType=upload` для целевого сервиса, стримит логи сборки через SSE и выводит живой URL по завершении. + +Если текущая директория ещё не привязана к проекту, `up` сначала запускает `init`. В интерактивном TTY это происходит в диалоговом режиме; в неинтерактивном окружении (CI) проект **не** создаётся автоматически — команда выдаёт ошибку и просит выполнить `lizard init --name ` (или передать `--name`), чтобы опечатка не привела к созданию пустого проекта. + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `-s, --service ` | Нацелиться на существующий сервис | +| `--build-command ` | Переопределить команду сборки | +| `--start-command ` | Переопределить команду запуска | +| `--pre-deploy-command ` | Выполнить один раз перед каждым деплоем | +| `--port ` | Порт контейнера (`0` = режим воркера) | +| `--region ` | Регион для деплоя | +| `-d, --detach` | Запустить деплой и выйти без стриминга логов | +| `-c, --ci` | Вывод, удобный для CI | +| `--no-gitignore` | Загрузить всё, игнорируя `.gitignore` | + + + +## Подкоманды + +### `lizard up status` + +Сообщает статус выполняемого деплоя с загрузкой. + + + +## Примеры + + + +### Деплой текущей директории + +```bash +lizard up +``` + + + +### Деплой в конкретный сервис с пользовательской командой запуска и портом + +Сначала создайте именованный сервис командой `lizard add --service api`, если он ещё не существует. + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +### Безголовый деплой в CI + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard add --service api +lizard up --ci --service api +``` + +Пропустите `lizard add`, если сервис уже существует. В Lizard CLI 0.3.92 неудачная сборка всё ещё может завершиться с кодом `0`; проверьте статус сборки и URL деплоя перед тем, как считать CI-релиз успешным. Исправление ожидает релиза. В macOS также задайте `COPYFILE_DISABLE=1` перед загрузкой, чтобы избежать лишних файлов метаданных `._*` в архиве. См. [настройку фреймворка](/framework-guides#prepare-the-project). + + + +## См. также + +- [Деплой из локального кода](/deploy/upload) — полное руководство по деплоям с загрузкой +- [lizard redeploy](/cli/redeploy) — пересобрать последнюю загрузку без повторной загрузки +- [lizard init](/cli/init) — явно создать или привязать проект перед деплоем +- [Воркеры](/deploy/workers) — что означает `--port 0` +- [Деплой контейнера без его настройки](https://lizard.build/blog/container-as-a-service#deploy-a-container-without-configuring-one) — где эта команда стоит среди платформ container-as-a-service diff --git a/_locales/ru/cli/upgrade.mdx b/_locales/ru/cli/upgrade.mdx new file mode 100644 index 0000000..4e737ff --- /dev/null +++ b/_locales/ru/cli/upgrade.mdx @@ -0,0 +1,50 @@ +--- +description: "lizard upgrade обновляет CLI на месте или проверяет наличие новой версии без установки с флагом --check." +--- + +# lizard upgrade + +Обновите CLI до последней версии. + + + +## Использование + +```bash +lizard upgrade [flags] +``` + + + +## Флаги + +| Флаг | Описание | +|------|-------------| +| `--check` | Проверить наличие новой версии без установки | + + + +## Примеры + + + +### Обновление до последней версии + +```bash +lizard upgrade +``` + + + +### Проверка обновлений без установки + +```bash +lizard upgrade --check +``` + + + +## См. также + +- [CLI reference](/cli) — установка, глобальные флаги, коды выхода +- [Getting started](/getting-started) — установка CLI в первый раз diff --git a/_locales/ru/cli/whoami.mdx b/_locales/ru/cli/whoami.mdx new file mode 100644 index 0000000..5f46a56 --- /dev/null +++ b/_locales/ru/cli/whoami.mdx @@ -0,0 +1,35 @@ +--- +description: "lizard whoami показывает учётную запись, в которую вы вошли, активное рабочее пространство и проект, привязанный к этой директории." +--- + +# lizard whoami + +Показывает текущего пользователя, активное рабочее пространство и привязанный проект. + + + +## Использование + +```bash +lizard whoami +``` + + + +## Примеры + + + +### Проверить, под кем вы вошли + +```bash +lizard whoami +``` + + + +## См. также + +- [lizard login](/cli/login) — аутентификация перед проверкой идентичности +- [lizard status](/cli/status) — показать привязанное рабочее пространство, проект и сервис для текущей директории +- [lizard workspace](/cli/workspace) — список доступных рабочих пространств diff --git a/_locales/ru/cli/workspace.mdx b/_locales/ru/cli/workspace.mdx new file mode 100644 index 0000000..5077c2a --- /dev/null +++ b/_locales/ru/cli/workspace.mdx @@ -0,0 +1,34 @@ +--- +description: "lizard workspace list показывает все рабочие пространства, доступные вашему аккаунту, и как они связаны с проектами и сервисами." +--- + +# lizard workspace + +Список доступных вам рабочих пространств. + + + +## Использование + +```bash +lizard workspace list +``` + + + +## Примеры + + + +### Список ваших рабочих пространств + +```bash +lizard workspace list +``` + + + +## См. также + +- [lizard whoami](/cli/whoami) — показывает ваше активное рабочее пространство +- [Architecture: Рабочая область](/concepts/architecture) — как рабочие пространства связаны с проектами и сервисами diff --git a/_locales/ru/concepts/_meta.ts b/_locales/ru/concepts/_meta.ts new file mode 100644 index 0000000..09ca460 --- /dev/null +++ b/_locales/ru/concepts/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Обзор", + architecture: "Архитектура", + 'build-pipeline': "Конвейер сборки", + deployments: "Развёртывания", +}; diff --git a/_locales/ru/concepts/architecture.mdx b/_locales/ru/concepts/architecture.mdx new file mode 100644 index 0000000..101bb2f --- /dev/null +++ b/_locales/ru/concepts/architecture.mdx @@ -0,0 +1,126 @@ +--- +description: "Как Lizard организует работу в рабочие пространства, проекты и сервисы, а также управляемые аддоны, межресурсные ссылки и внедряемые переменные." +--- + + + +# Архитектура + +Lizard организует всё, что вы деплоите, в иерархию из трёх уровней, плюс управляемые аддоны, прикреплённые к проекту. + +``` +workspace +└── project + ├── service (app) ← built from GitHub or an upload + ├── service (worker) ← background job, no HTTP port + └── addons + ├── postgres + ├── redis + └── s3 +``` + + + +## Рабочее пространство + +**Рабочее пространство** — это уровень аккаунта или организации. Вы состоите хотя бы в одном, а биллинг, участники и проекты находятся в нём. Посмотреть доступные: + +```bash +lizard workspace list +lizard whoami # shows your active workspace +``` + +Многие команды принимают `-w, --workspace `, чтобы уточнить цель, когда одноимённые проекты существуют в разных рабочих пространствах. + + + +## Проект + +**Проект** объединяет связанные сервисы и аддоны внутри рабочего пространства. Ваша рабочая директория *связывается* с проектом, и эта связь (хранится в `~/.lizard/config.json`) сообщает CLI, с чем вы работаете. + +```bash +lizard init --name my-project # create or select a project, link the cwd +lizard link --project my-project # link to an existing project +lizard status # show the current directory's link +lizard unlink # remove the link +lizard project list # all projects in the workspace +``` + +> **Совет:** Используйте имя репозитория или директории для проекта, а для сервисов — имена в стиле приложений (`api`, `worker`, `web`). + + + +## Сервис + +**Сервис** — это единица деплоя. Его источник может быть одним из: + +- **`github`** — подключённый репозиторий GitHub. Пуш в отслеживаемую ветку вызывает повторный деплой. +- **`upload`** — тарболл, загруженный через `lizard up`. + +Каждый запущенный сервис работает как отдельный **изолированный под** с политикой сети default-deny, сгенерированным доменом `..onlizard.com` и автоматическим TLS. Это разделение — вы предоставляете контейнер, платформа его запускает — называется [container as a service](https://lizard.build/blog/container-as-a-service), а в блоге описано, что ещё остаётся на вашей стороне. Инспектировать и управлять сервисами можно с помощью: + +```bash +lizard ps # list services with status + URL +lizard service show # full config as JSON +lizard service set --set = +lizard service rename --service +lizard service delete --service +``` + +Поля конфигурации сервиса **плоские** и отображаются 1:1 в схему на проводе (например, `repoUrl`, `branch`, `buildCommand`, `startCommand`, `containerPort`, `rootDirectory`). Вложенности `build.*` / `deploy.*` нет. Полный список см. в [`lizard service`](/cli/service). + + + +### App-сервисы и воркеры + +По умолчанию сервис — **HTTP-приложение**, слушающее порт (по умолчанию `3000`) и доступное на своём домене. Сервису, который не слушает порт — потребителю очереди, реконсилеру или поллинговому циклу — следует запускаться в [**режиме воркера**](/deploy/workers), установив `containerPort=0`. Воркеры пропускают инъекцию порта, проверку достижимости и регистрацию в балансировщике. + + + +## Управляемые аддоны + +**Аддоны** — это управляемые Postgres, Redis и S3-совместимое хранилище, которые вы создаёте на уровне проекта: + +```bash +lizard add postgres redis s3 +``` + +Каждый аддон предоставляет фиксированный набор переменных окружения, которые сервисы используют по **ссылке** (`${{.KEY}}`). Подробнее в разделе [Управляемые аддоны](/addons). + + + +## Межресурсные ссылки + +Любое значение сервиса или аддона можно сослаться из окружения другого ресурса с помощью: + +``` +${{.}} +``` + +Ссылки разрешаются **во время деплоя** против объединённого окружения цели. Они хранятся по ID, поэтому последующее переименование цели не ломает ссылку. Ссылка на несуществующую цель или ключ разрешается в пустую строку (деплой **не** падает); выбрасывают ошибку только циклические ссылки. + +```bash +# Wire a service to the project's Postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + +Проверить, что потребитель действительно получил значение: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + + + +## Переменные, внедряемые платформой + +Каждый сервис автоматически получает эти переменные (их нельзя переопределить): + +| Переменная | Описание | +|----------|-------------| +| `PORT` | Порт, который должно слушать приложение (отсутствует в режиме воркера) | +| `LIZARD_SERVICE_NAME` | Имя сервиса | +| `LIZARD_PROJECT_ID` | ID проекта | +| `LIZARD_PUBLIC_DOMAIN` | Публичный домен сервиса | + +Как они взаимодействуют с вашими переменными и полный порядок приоритетов см. в разделе [Переменные и секреты](/variables). diff --git a/_locales/ru/concepts/build-pipeline.mdx b/_locales/ru/concepts/build-pipeline.mdx new file mode 100644 index 0000000..4024c6b --- /dev/null +++ b/_locales/ru/concepts/build-pipeline.mdx @@ -0,0 +1,89 @@ +--- +description: "Как Lizard превращает исходный код в образ контейнера: синтезированный Dockerfile, Dockerfile из репозитория, автоопределение lizardpack, и что запускает пересборку." +--- + + + +# Конвейер сборки + +Сборки выполняются на узлах сборки Lizard — **вам не нужен Docker локально**. При развёртывании платформа по заданному порядку решает, как превратить ваш исходный код в образ контейнера, а затем запускает этот образ в изолированном поде. Не каждый [контейнер как сервис](https://lizard.build/blog/container-as-a-service) собирает образ за вас; в блоге сравниваются три формы, в которых встречается эта категория. + + + +## Порядок выбора стратегии сборки + +Платформа выбирает ровно одну стратегию сборки, в таком порядке: + +1. **Синтезированный Dockerfile** — если на сервисе заданы `buildCommand` и/или `startCommand` (или переданы через `lizard up --build-command` / `--start-command`), Lizard генерирует Dockerfile из этих команд. lizardpack не вызывается. +2. **Dockerfile из репозитория (как есть)** — если на сервисе задан `dockerfilePath`, используется тот Dockerfile из вашего репозитория без изменений. +3. **Автоопределение lizardpack** — иначе платформа клонирует ваш исходный код и запускает **lizardpack**, свой генератор Dockerfile / buildpack. + + + +### Автоопределение lizardpack + +lizardpack анализирует ваш репозиторий и собирает оптимизированный многостадийный образ. Поддерживаемые стеки, проверяемые в таком порядке: + +**Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static** + +См. [Руководства по фреймворкам](/framework-guides) для продакшн-скриптов, адаптеров, путей вывода и портов. Определение использует файлы проекта и зависимости; репозиторий, подходящий под несколько провайдеров, следует этому порядку. + +На этом пути: + +- Если в репозитории есть `Dockerfile` **и** в нём есть реальный шаг сборки (строка `RUN `, а не только `COPY dist/`), он используется как есть. +- Иначе lizardpack генерирует Dockerfile за вас. +- **Команда запуска** определяется автоматически: строка `Procfile` `web:` (Python/Ruby) или `package.json` `scripts.start` (Node) подхватывается автоматически. Для точной строки, которую хотят Django, Flask и FastAPI, см. [Хостинг Python-приложений](https://lizard.build/blog/python-app-hosting). +- **Порт** выводится из `EXPOSE`, значений фреймворка по умолчанию или явной переменной окружения `PORT`. + +> **Подвох:** Dockerfile, который только копирует предварительно собранные артефакты (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) **без** шага сборки `RUN`, считается неполным и регенерируется lizardpack. Добавьте реальный шаг сборки или задайте `dockerfilePath` для принудительного использования как есть. + + + +## Что вызывает пересборку + +| Действие | Пересобирает? | +|----------|---------------| +| `git push` в отслеживаемую ветку | ✅ через вебхук GitHub | +| `lizard redeploy` / `lizard up` | ✅ явно | +| Изменение переменных `VITE_*` или `NEXT_PUBLIC_*` | ✅ значения времени сборки запекаются в образ | +| `service set` полей сборки (`repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath`, `rootDirectory`) | ✅ автопересборка | +| `service set` полей только времени выполнения (`startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns`) | ❌ запустите `lizard redeploy` для применения | +| Любое другое изменение переменной окружения / секрета | ❌ применяется при быстром перезапуске (без пересборки) | + +> **Не дублируйте сборку.** После `service set`, меняющего поле сборки, пересборка запускается автоматически — не ставьте в цепочку `lizard redeploy` после этого, иначе поставите в очередь вторую избыточную сборку. + + + +## Наблюдение за сборкой + +Логи сборки стримятся во время `lizard up`. Для любого сервиса: + +```bash +lizard logs --build # the most recent build's logs +lizard events # deploy history + replica status +``` + +Если сборка упала, прочитайте `lizard logs --build`, устраните причину (в репозитории или скорректировав `buildCommand` / `startCommand` через `lizard service set`), затем `lizard redeploy`. + + + +## Примечания к рантайму + +- **Нет Docker `HEALTHCHECK`.** Рантайм не запускает цикл healthcheck Docker, поэтому директивы `HEALTHCHECK` игнорируются. Lizard выполняет TCP-пробирование вашего порта вместо этого (пропускается в [режиме воркера](/deploy/workers)). +- **Не пишите Dockerfile без нужды.** lizardpack автоопределяет большинство стеков — попробуйте сначала задеплоить, и добавляйте Dockerfile (или задавайте `dockerfilePath`) только если автосборка не подходит. + + + +## Справочник по конфигурации сборки + +| Поле | Описание | +|------|----------| +| `buildCommand` | Команда сборки вашего приложения → принудительно использует путь **синтезированного Dockerfile** | +| `startCommand` | Команда запуска приложения во время выполнения | +| `preDeployCommand` | Выполняется один раз перед каждым деплоем (например, миграции БД) | +| `dockerfilePath` | Путь к Dockerfile в репозитории для использования **как есть** | +| `rootDirectory` | Поддиректория для сборки (монорепозитории) | +| `watchPatterns` | Передеплой только при изменении соответствующих путей | +| `containerPort` | TCP-порт, который слушает приложение (по умолчанию `3000`; `0` = [воркер](/deploy/workers)) | + +Любое из этих полей можно задать через `lizard service set --set =`. См. [`lizard service`](/cli/service). diff --git a/_locales/ru/concepts/deployments.mdx b/_locales/ru/concepts/deployments.mdx new file mode 100644 index 0000000..cdc6d12 --- /dev/null +++ b/_locales/ru/concepts/deployments.mdx @@ -0,0 +1,95 @@ +--- +description: "Жизненный цикл деплоя в Lizard: что запускает сборку, как трафик переключается на здоровые реплики и чем перезапуск отличается от повторного деплоя." +--- + + + +# Деплои + +**Деплой** — это одна сборка и выпуск сервиса. Путь выпуска зависит от среды выполнения сервиса. Успешная сборка сама по себе не гарантирует, что приложение запустилось или может обслуживать запросы. + + + +## Как происходит деплой + +Деплой запускается при любом из следующих событий: + +- **`git push`** в отслеживаемую ветку (для сервисов из `github`). +- **`lizard redeploy`** — повторная сборка из последнего коммита (git) или последней загрузки с текущими переменными. +- **`lizard up`** — загрузка текущей директории и её деплой. +- **`service set`**, изменяющее поле, влияющее на сборку. + +```bash +lizard redeploy --service api # rebuild + redeploy from current source +lizard up # upload cwd and deploy +``` + + + +## Жизненный цикл + +1. **Сборка** — платформа запускает вашу сборку (см. [Конвейер сборки](/concepts/build-pipeline)). +2. **Пред-деплой** — если задан `preDeployCommand`, он выполняется один раз (например, миграции). +3. **Запуск** — Lizard запускает приложение для настроенной среды выполнения. +4. **Проверка работоспособности** — платформа проверяет, что порт приложения доступен (пропускается для [воркеров](/deploy/workers)). +5. **Верификация** — проверьте статус выпуска и вызовите URL приложения. Доступность порта — не полная проверка работоспособности приложения. + + + +## Потоковый вывод + +При запуске не-детачированного `lizard up` (или `redeploy`) логи сборки стримятся в прямом эфире. С `--json` вы получаете по одному JSON-событию на строку: + +```json +{ "event": "log", "line": "..." } +{ "event": "deployed", "status": "...", "url": "https://..." } +``` + +завершающееся `deployed`, `failed` или `deploying`. Используйте `--detach`, чтобы запустить деплой и вернуть управление сразу, без стриминга. + + + +## Просмотр истории + +```bash +lizard events # deploy history + per-replica status +lizard events --limit 25 # show more +lizard ps # current services, status, and URLs +``` + +В [дашборде](/dashboard) представление **Деплои** показывает полную таймлайн, логи сборки для каждого деплоя и панель деталей для каждого выпуска. + + + +## Перезапуск против повторного деплоя + +| Команда | Что делает | +|---------|--------------| +| `lizard restart --service ` | Перезапуск **текущей** сборки — без повторной сборки | +| `lizard redeploy --service ` | Новая **сборка** из последнего коммита/загрузки, затем выпуск | + +Используйте `restart` для перезапуска реплик (например, чтобы подхватить секрет среды выполнения, который не применился горячей перезагрузкой); используйте `redeploy`, когда нужна новая сборка. + + + +## Восстановление после сбоя + +Посмотрите логи последнего сбоя или перезапуска: + +```bash +lizard logs --restart latest # log tail around the latest restart +lizard logs --restart # a specific restart +lizard events # see replica status +``` + + + +## Изменения конфигурации (без пересборки) + +Большинство изменений переменных окружения и секретов применяются без пересборки: Lizard обновляет конфигурацию сервиса и перезапускает его, что занимает несколько секунд. Значения времени сборки (`VITE_*`, `NEXT_PUBLIC_*`) и изменения полей сборки заставляют пересобирать — см. [таблицу триггеров пересборки](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Неудачные выпуски и восстановление + +Неудачная сборка и неудачный запуск приложения — это разные случаи. Не предполагайте, что старый выпуск продолжает обслуживать запросы в любой среде выполнения. Проверьте активный сервис, логи сборки и логи среды выполнения. `lizard redeploy` собирает выбранный источник заново; это не команда для восстановления предыдущей сборки. При необходимости верните исходный коммит, задеплойте его и проверьте результат. См. [известные проблемы](/platform/known-issues). diff --git a/_locales/ru/concepts/index.mdx b/_locales/ru/concepts/index.mdx new file mode 100644 index 0000000..cca7f2e --- /dev/null +++ b/_locales/ru/concepts/index.mdx @@ -0,0 +1,19 @@ +--- +description: "Базовая модель Lizard: как организован код, как он собирается и как релиз попадает в продакшн." +--- + + + +# Концепции + +Базовая модель Lizard: как организован ваш код, как он собирается и как релиз достигает продакшена. Прочитайте это один раз, и остальная документация станет понятной. + +Для модели более высокого уровня — что такое платформа, запускающая ваш контейнер, и чем она отличается от PaaS, FaaS и IaaS — читайте статью [container as a service](https://lizard.build/blog/container-as-a-service) в блоге. + + + +## В этом разделе + +- [Architecture](/concepts/architecture) — иерархия workspace → project → service, управляемые аддоны и перекрёстные ссылки между ресурсами. +- [Конвейер сборки](/concepts/build-pipeline) — как исходный код превращается в образ контейнера (синтезируемый Dockerfile, Dockerfile из репозитория или автоопределение через lizardpack) и что запускает пересборку. +- [Развертывания](/concepts/deployments) — жизненный цикл сборки и релиза, отличия рестартов от редеплоев и применение изменений конфигурации в живом режиме. diff --git a/_locales/ru/dashboard.mdx b/_locales/ru/dashboard.mdx new file mode 100644 index 0000000..7fd4b9d --- /dev/null +++ b/_locales/ru/dashboard.mdx @@ -0,0 +1,96 @@ +--- +description: "Что дашборд Lizard добавляет к CLI: статус сервисов, история деплоев, логи в реальном времени, метрики, браузеры данных, команда и биллинг." +--- + + + +# Дашборд приложения + +Дашборд Lizard — это визуальный спутник CLI. Все, что вы делаете с `lizard …`, отображается здесь, плюс то, что удобнее делать через UI — логи в реальном времени, графики, браузеры данных, управление командой и биллингом. + +Если вы не хотите открывать терминал вообще, пусть агент выполняет команды, а вы следите за результатом здесь — путь в [деплое Antigravity-приложения в прод](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#deploy-an-antigravity-app-to-production-without-typing-a-command), который занимает два промпта и ни строчки в терминале. + +Открыть из CLI: + +```bash +lizard open # open the current project +lizard docs # open this documentation +``` + + + +## Что есть в дашборде + + + +### Сервисы + +Домашняя страница проекта показывает каждый сервис с бейджем статуса, сгенерированным доменом и быстрыми переходами к логам, метрикам, секретам и настройкам. Создавайте новые сервисы (из GitHub-репозитория или пустые) прямо отсюда. + + + +### Деплои + +Хронология каждого деплоя с логами сборки на уровне деплоя и детальной панелью (коммит, статус, реплики). Это визуальный аналог `lizard events` + `lizard logs --build`. + + + +### Логи + +Стриминг логов рантайма и сборки в реальном времени с поиском и фильтрами по уровню — UI-аналог [`lizard logs`](/observability/logs). + + + +### Метрики и использование + +Графики CPU, памяти, сети и диска на сервис, а также представление **Использование**, которое разбивает потребление и стоимость по проекту. Зеркалит [`lizard metrics --cost`](/observability/metrics). + + + +### Переменные и секреты + +Управление секретами уровня сервиса и проекта, с маскированными значениями и поддержкой ссылок (`${{…}}`). См. [Переменные и секреты](/variables). + + + +### Домены + +Добавляйте собственные домены, просматривайте DNS-записи и отслеживайте статус верификации и TLS. См. [Сеть](/networking). + + + +### Браузеры управляемых аддонов + +У каждого аддона свой браузер данных: + +- **Postgres** — SQL/табличный редактор для запросов и редактирования данных. +- **Redis** — браузер ключ/значение. +- **S3** — браузер бакетов и объектов с загрузкой/скачиванием. + + + +### Интеграция с GitHub + +Подключите GitHub App, выберите репозитории и управляйте тем, какие репозитории может собирать Lizard. См. [Деплой из GitHub](/deploy/github). + + + +### Настройки, команда и биллинг + +Настройки проекта и рабочего пространства, приглашения участников и роли, использование ресурсов, средства на балансе и опциональный автопополнение. Стандартные аккаунты работают по модели [pay as you go](/platform/billing) без ежемесячной подписки. + + + +## CLI ↔ Дашборд + +| Задача | CLI | Представление в дашборде | +|--------|-----|------------------------| +| История деплоев | `lizard events` | Деплои | +| Стриминг логов | `lizard logs` | Логи | +| Графики ресурсов | `lizard metrics` | Метрики / Использование | +| Управление секретами | `lizard secrets` | Переменные | +| Собственные домены | `lizard domain` | Домены | +| Браузер Postgres/Redis/S3 | `lizard run` / `lizard ssh` | Браузеры аддонов | +| Пригласить коллег | — | Команда / Настройки | + +Используйте то, что удобнее в момент — они работают с одними и теми же проектами и сервисами. diff --git a/_locales/ru/deploy/_meta.ts b/_locales/ru/deploy/_meta.ts new file mode 100644 index 0000000..1d8d3e5 --- /dev/null +++ b/_locales/ru/deploy/_meta.ts @@ -0,0 +1,9 @@ +export default { + index: "Обзор", + github: "Деплой из GitHub", + upload: "Деплой локального кода", + workers: "Фоновые воркеры", + scaling: "Масштабирование", + regions: "Регионы", + troubleshooting: "Устранение неполадок", +}; diff --git a/_locales/ru/deploy/github.mdx b/_locales/ru/deploy/github.mdx new file mode 100644 index 0000000..e0cee5d --- /dev/null +++ b/_locales/ru/deploy/github.mdx @@ -0,0 +1,100 @@ +--- +description: "Подключите репозиторий GitHub, чтобы каждый push в отслеживаемую ветку запускал сборку и переразвёртывание, включая приватные репозитории, смену веток и монорепозитории." +--- + + + +# Развёртывание из GitHub + +Подключение репозитория GitHub — рекомендуемый способ запуска приложения на Lizard: каждый push в отслеживаемую ветку автоматически собирает и переразвёртывает приложение. + + + +## Создание сервиса из репозитория + +```bash +lizard add -r your-org/your-app +``` + +Это создаёт `github`-сервис, клонирует репозиторий, автоматически определяет стек ([lizardpack](/concepts/build-pipeline)), собирает его и возвращает работающий URL. Полезные флаги: + +| Флаг | Назначение | +|------|------------| +| `-r, --repo ` | Исходный репозиторий | +| `-n, --name ` | Имя сервиса (используется в ссылках `${{name.KEY}}` и на панели управления) | +| `-v, --variables ` | Задать переменную окружения; можно повторять | +| `--region ` | Регион для развёртывания | +| `--no-deploy` | Подключить репозиторий, но пропустить первую сборку | + + + +## Приватные репозитории + +Подключите приложение Lizard для GitHub один раз на аккаунт, чтобы получить доступ к приватным репозиториям: + +```bash +lizard git connect +lizard git status # show connection + repo status +``` + +Также можно подключить репозитории и управлять доступом на странице **GitHub integration** в панели управления (`lizard open`). + + + +## Подключение существующего сервиса к репозиторию + +Чтобы переключить сервис на git-источник (или сменить репозиторий/ветку): + +```bash +lizard service set api \ + --set sourceType=github \ + --set repoUrl=https://github.com/your-org/your-app \ + --set branch=main +``` + +Изменение поля сборки автоматически запускает пересборку — **не** добавляйте `redeploy` после этого. + +> **Примечание:** `lizard up` всегда принудительно включает `sourceType=upload`. Не используйте его для обновления git-сервиса — отправьте push в удалённый репозиторий или используйте `lizard redeploy`. + + + +## Автоматическое переразвёртывание при push + +После настройки `repoUrl` пуши в соответствующую `branch` автоматически переразвёртывают сервис через вебхук GitHub. Чтобы ограничить, какие пуши запускают переразвёртывание: + +- **`rootDirectory`** — собирать только подкаталог (монорепозитории). +- **`watchPatterns`** — переразвёртывать только при изменении соответствующих путей. + +```bash +lizard service set api --set watchPatterns='apps/api/**,packages/**' +``` + + + +## Смена веток + +```bash +lizard git checkout api staging # move the `api` service to the `staging` branch and redeploy +``` + + + +## Монорепозитории + +Для репозитория с несколькими приложениями создайте отдельный сервис для каждого и укажите его `rootDirectory` как подпуть: + +```bash +lizard add -r your-org/monorepo -n api +lizard service set api --set rootDirectory=apps/api +``` + +Если текущая директория — под-приложение внутри репозитория, чей родитель уже подключен, добавьте сервис в проект родителя и укажите `rootDirectory` как подпуть от cwd. + + + +## См. также + +- [Сборка Pipeline](/concepts/build-pipeline) — как стек определяется и собирается. +- [Развернуть из локального кода](/deploy/upload) — когда нет удалённого репозитория. +- [`lizard git`](/cli/git) — полная справочная информация по командам `connect`, `status` и `checkout`. +- [Куда развернуть приложение, созданное вашим AI IDE](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#where-to-deploy-an-app-your-ai-ide-built) — подключение к репозиторию, написанному агентом, и стоимость. diff --git a/_locales/ru/deploy/index.mdx b/_locales/ru/deploy/index.mdx new file mode 100644 index 0000000..b253eba --- /dev/null +++ b/_locales/ru/deploy/index.mdx @@ -0,0 +1,22 @@ +--- +description: "Всё о запуске сервиса на Lizard и его поддержке: деплой из GitHub и локально, воркеры, масштабирование, регионы и решение проблем." +--- + + + +# Деплой + +Всё о запуске сервиса на Lizard и его поддержке — от первого пуша до масштабирования и размещения по регионам. + +Сравниваете с другим хостингом? В блоге девять платформ [container as a service](https://lizard.build/blog/container-as-a-service) сравнены ценообразованием рядом. + + + +## В этом разделе + +- [Деплой из GitHub](/deploy/github) — подключите репозиторий, чтобы пуши в отслеживаемую ветку автоматически перезапускали деплой. +- [Деплой из локального кода](/deploy/upload) — отправьте текущую директорию с помощью `lizard up`, Git не требуется. +- [Фоновые воркеры](/deploy/workers) — запускайте потребители очередей и поллинг-циклы с `containerPort=0`. +- [Масштабирование](/deploy/scaling) — настраивайте реплики, ресурсы и хранилище. +- [Регионы](/deploy/regions) — где запускаются ваши сервисы. +- [Устранение неполадок](/deploy/troubleshooting/incomplete-dockerfile) — решения для самых частых проблем при сборке и деплое. diff --git a/_locales/ru/deploy/regions.mdx b/_locales/ru/deploy/regions.mdx new file mode 100644 index 0000000..ca5edfa --- /dev/null +++ b/_locales/ru/deploy/regions.mdx @@ -0,0 +1,40 @@ +--- +description: "Выбирайте, где будут работать ваши сервисы и аддоны, размещайте состояние в одном регионе для низкой задержки и узнавайте, как регион влияет на генерируемые домены." +--- + + + +# Регионы + +Сервисы и аддоны создаются в конкретном регионе. Посмотрите список регионов, доступных вашему аккаунту, и выберите нужный при создании. + + + +## Список регионов + +```bash +lizard regions +lizard regions --json +``` + + + +## Выбор региона + +Передайте `--region ` при создании сервиса или аддона: + +```bash +lizard add -r your-org/your-app --region +lizard add postgres --region +lizard up --region +``` + +Если регион не указан, платформа использует регион проекта по умолчанию. + +> **Размещайте состояние в одном регионе.** Размещайте сервис и аддоны, с которыми он общается (Postgres, Redis, S3), в **одном регионе**, чтобы сохранить низкую задержку и избежать платы за межрегиональный трафик. + + + +## Генерируемые домены + +Каждый сервис получает генерируемый домен на `*.onlizard.com` с автоматическим TLS, независимо от региона. Объектное хранилище от [S3-аддона](/addons/storage) использует шлюз с учётом региона (`s3-.onlizard.com`). Чтобы подключить свой хостнейм, см. [Networking](/networking). diff --git a/_locales/ru/deploy/scaling.mdx b/_locales/ru/deploy/scaling.mdx new file mode 100644 index 0000000..c10f55b --- /dev/null +++ b/_locales/ru/deploy/scaling.mdx @@ -0,0 +1,78 @@ +--- +description: "Добавьте реплики или увеличьте CPU и память для сервиса, а также увеличьте хранилище аддона. Допустимые диапазоны, поведение при развертывании и как проверить изменение." +--- + + + +# Масштабирование + +Масштабируйте сервис горизонтально (больше реплик) или вертикально (больше CPU/памяти) с помощью `lizard scale`. Хранилище аддонов увеличивается тем же способом. + + + +## Масштабирование сервиса + +```bash +lizard scale --service api --replicas 3 +lizard scale --service api --cpu 2 --memory 2048 +``` + +| Флаг | Применяется к | Допустимые значения | +|------|-----------|----------------| +| `--replicas ` | приложения | `1`–`10` | +| `--cpu ` | приложения | целые ядра: `1`, `2`, `3`, `4` | +| `--memory ` | приложения | `128`–`8192` МБ (шаг 1 МБ) | +| `--storage ` | **только аддоны**, только увеличение | `512`, `1024`, `2048`, `4096`, `8192`, `16384` | + +Флаги можно комбинировать в одной команде. Изменение количества реплик разворачивается без пересборки. + + + +## Горизонтальное масштабирование + +Запустите несколько реплик приложения за балансировщиком нагрузки: + +```bash +lizard scale --service api --replicas 5 +``` + +Каждая реплика — это отдельный под. Убедитесь, что ваше приложение бесстаточное (храните состояние в [Postgres](/addons/postgres), [Redis](/addons/redis) или [S3](/addons/storage)), чтобы реплики были взаимозаменяемыми. + + + +## Вертикальное масштабирование + +Дайте одной реплике больше ресурсов: + +```bash +lizard scale --service api --cpu 4 --memory 8192 +``` + + + +## Увеличение хранилища аддонов + +Тома данных аддонов **только для увеличения** — вы можете увеличить хранилище, но не уменьшить его: + +```bash +lizard scale --service postgres --storage 8192 +``` + + + +## Проверка + +```bash +lizard ps # replica status + URL +lizard events # per-replica deploy/scale history +lizard metrics # live CPU / memory / network / disk +lizard metrics --cost # include cost +``` + + + +## См. также + +- [Наблюдаемость → Метрики](/observability/metrics) — мониторинг ресурсов и затрат. +- [`lizard scale`](/cli/scale) — полная справочная информация по командам. +- [Сколько берут провайдеры CaaS в 2026](https://lizard.build/blog/container-as-a-service#what-caas-providers-charge-in-2026) — тарифы за vCPU, за ГБ и исходящий трафик на девяти платформах, для оценки счёта до масштабирования. diff --git a/_locales/ru/deploy/troubleshooting/_meta.ts b/_locales/ru/deploy/troubleshooting/_meta.ts new file mode 100644 index 0000000..0894797 --- /dev/null +++ b/_locales/ru/deploy/troubleshooting/_meta.ts @@ -0,0 +1,5 @@ +export default { + 'incomplete-dockerfile': "Изменения в Dockerfile не применяются", + 'double-build': "Изменение поставило в очередь две сборки", + 'service-never-healthy': "Сервис так и не становится здоровым", +}; diff --git a/_locales/ru/deploy/troubleshooting/double-build.mdx b/_locales/ru/deploy/troubleshooting/double-build.mdx new file mode 100644 index 0000000..f5707fe --- /dev/null +++ b/_locales/ru/deploy/troubleshooting/double-build.mdx @@ -0,0 +1,53 @@ +--- +description: "Почему команда изменения сервиса с последующим переразвёртыванием ставит в очередь две сборки, какие поля инициируют пересборку самостоятельно, и как избежать лишней." +--- + + + +# Моё изменение поставило в очередь две сборки подряд + +Вы выполнили `lizard service set` для изменения поля, затем `lizard redeploy`, и в итоге получили две сборки вместо одной. + + + +## Что это значит + +Вызов `service set` уже запустил пересборку сам по себе. Последующий вызов `redeploy` поставил в очередь вторую, лишнюю. + + + +## Почему так происходит + +Изменение поля, **влияющего на сборку** — `repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath` или `rootDirectory` — немедленно запускает автопересборку. Изменение поля **только для рантайма** — `startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns` — **не** запускает автопересборку; оно вступает в силу только при следующем деплое. + +Легко инстинктивно цеплять `redeploy` после каждого `service set`, но это имеет смысл только для полей только для рантайма. + + + +## Возможные решения + + + +### Проверьте, поле какого типа вы изменили + +См. [таблицу триггеров пересборки](/concepts/build-pipeline#what-triggers-a-rebuild). Если это поле сборки, пересборка уже в очереди — больше ничего делать не нужно. + +```bash +lizard events # confirm only one build is in flight +``` + + + +### Переразвёртывайте только после изменений полей только для рантайма + +```bash +lizard service set api --set startCommand="node server.js" +lizard redeploy --service api # needed here — startCommand doesn't auto-rebuild +``` + + + +## См. также + +- [Сборка Pipeline → что запускает пересборку](/concepts/build-pipeline#what-triggers-a-rebuild) +- [`lizard service`](/cli/service) — полный справочник команд. diff --git a/_locales/ru/deploy/troubleshooting/incomplete-dockerfile.mdx b/_locales/ru/deploy/troubleshooting/incomplete-dockerfile.mdx new file mode 100644 index 0000000..12269af --- /dev/null +++ b/_locales/ru/deploy/troubleshooting/incomplete-dockerfile.mdx @@ -0,0 +1,57 @@ +--- +description: "Почему Lizard заменяет Dockerfile репозитория, в котором нет шага сборки, как работает правило неполного Dockerfile и как заставить использовать ваш файл как есть." +--- + + + +# Мои изменения в Dockerfile не применяются + +В вашем репозитории есть `Dockerfile`, вы его отредактировали, но сборка, которую запускает Lizard, не соответствует вашему файлу. + + + +## Что это значит + +Платформа сочла Dockerfile репозитория **неполным** и сгенерировала новый с помощью [lizardpack](/concepts/build-pipeline), вместо того чтобы использовать ваш файл в исходном виде. + + + +## Почему это может произойти + +Lizard использует Dockerfile репозитория **как есть** только на пути автоопределения lizardpack, если в нём есть настоящий шаг сборки — строка `RUN `. Dockerfile, который лишь копирует предварительно собранные артефакты (`COPY dist/`, `build/`, `out/`, `.next/`, `public/`) без шага `RUN`, считается неполным — подразумевается, что эти артефакты собраны вне образа. В таком случае lizardpack создаёт заменяющий Dockerfile, включающий недостающий шаг сборки. + +Это касается только пути автоопределения lizardpack. Если для сервиса заданы `buildCommand` или `startCommand`, Lizard синтезирует Dockerfile из этих команд и вообще не смотрит на Dockerfile в репозитории. + + + +## Возможные решения + + + +### Добавьте настоящий шаг сборки + +Если хотите, чтобы ваш Dockerfile использовался как есть, добавьте в него реальный шаг сборки вместо копирования готового результата: + +```dockerfile +RUN npm ci && npm run build +``` + + + +### Или заставьте использовать файл дословно + +Очистите переопределения сборки и запуска, затем задайте `dockerfilePath` в том же обновлении. Переопределения имеют приоритет над путем к файлу: + +```bash +lizard service set api --set buildCommand=null --set startCommand=null --set dockerfilePath=Dockerfile +``` + + + +## См. также + +- [Конвейер сборки](/concepts/build-pipeline) — полный порядок принятия решений о сборке. +- [Справочник по настройке сборки](/concepts/build-pipeline#build-configuration-reference) +- [Развёртывание любого Python-приложения на Lizard](https://lizard.build/blog/python-app-hosting#deploying-any-python-app-on-lizard) — когда позволить lizardpack написать Dockerfile и когда принести свой. + +Изменение этих полей сборки может запустить сборку. Проверьте `lizard events` перед отправкой очередного `redeploy`, чтобы не запустить вторую сборку случайно. diff --git a/_locales/ru/deploy/troubleshooting/service-never-healthy.mdx b/_locales/ru/deploy/troubleshooting/service-never-healthy.mdx new file mode 100644 index 0000000..ef45fce --- /dev/null +++ b/_locales/ru/deploy/troubleshooting/service-never-healthy.mdx @@ -0,0 +1,59 @@ +--- +description: "Сборка проходит успешно, но деплой остаётся нездоровым. Привязка порта, случайный рабочий режим и другие причины провала проверки здоровья." +--- + + + +# Моя служба деплоится, но никогда не становится здоровой + +Сборка проходит успешно, реплики запускаются, но деплой остаётся в ожидании, помечается как нездоровый или никогда не начинает принимать трафик. + + + +## Что это значит + +Проверка здоровья платформы — которая проверяет доступность порта вашего приложения — никогда не проходит, поэтому трафик никогда не переключается на новые реплики. + + + +## Почему это может происходить + +- **Ваше приложение не слушает ожидаемый порт.** Lizard внедряет переменную окружения `PORT` (порт контейнера по умолчанию `3000`) и проверяет, что ваше приложение доступно там. Если ваше приложение жестко задано на другой порт или никогда не привязывает порт, проверка здоровья бесконечно проваливается. Типичный случай — Python-приложение: `gunicorn` и `uvicorn` привязывают `127.0.0.1`, если вы не скажете им иначе, а проверка приходит извне процесса. В [хостинге Python-приложений](https://lizard.build/blog/python-app-hosting#what-a-python-app-actually-needs-from-a-host) указана строка `--bind 0.0.0.0:$PORT`, которую требует каждый фреймворк. +- **Служба случайно перешла в рабочий режим.** Установка `containerPort=0` переводит службу в [рабочий режим](/deploy/workers), который **полностью пропускает проверку здоровья и регистрацию в балансировщике нагрузки**. Служба, которая должна обслуживать HTTP, но получила `containerPort=0`, будет деплоиться «успешно» и просто никогда ничего не обслуживать — рабочий режим скрывает базовую проблему запуска вместо того, чтобы выявить её. + + + +## Возможные решения + + + +### Проверьте текущий порт + +```bash +lizard port --service api +``` + +Если это выводит `worker mode`, у службы установлен `containerPort=0`. Верните его на реальный порт, если эта служба предназначена для обслуживания HTTP: + +```bash +lizard port 3000 --service api +lizard redeploy --service api +``` + + + +### Убедитесь, что ваше приложение слушает там, где ожидает Lizard + +Прочитайте логи среды выполнения на предмет ошибок запуска и сверьте порт, который фактически привязало приложение, с тем, что внедрил Lizard: + +```bash +lizard logs --service api +lizard ssh --service api -- env | grep PORT +``` + + + +## См. также + +- [Фоновые рабочие процессы](/deploy/workers) — когда `containerPort=0` уместен, а когда нет. +- [Деплойменты → жизненный цикл](/concepts/deployments#lifecycle) — где проверка здоровья находится в деплойменте. diff --git a/_locales/ru/deploy/upload.mdx b/_locales/ru/deploy/upload.mdx new file mode 100644 index 0000000..6748b8c --- /dev/null +++ b/_locales/ru/deploy/upload.mdx @@ -0,0 +1,82 @@ +--- +description: "Разверните текущую директорию с помощью lizard up без необходимости в Git. Описана работа с gitignore, переопределение команд сборки и запуска, а также использование в headless CI." +--- + + + +# Развертывание из локального кода + +Когда ваш код не на GitHub — или вы просто хотите итерироваться быстрее — загрузите текущую директорию напрямую с помощью `lizard up`. Она упаковывает вашу рабочую директорию в tarball, отправляет на узлы сборки и развертывает. + + + +## Развернуть текущую директорию + +```bash +lizard up +``` + +- Загружает текущую директорию как tarball, уважая `.gitignore` (отключается через `--no-gitignore`). +- Принудительно включает `sourceType=upload`. +- Выводит логи сборки через SSE и печатает живой URL по завершении. + +Если директория ещё не привязана к проекту, `up` сначала запускает `init`. В интерактивном TTY это происходит в диалоговом режиме; в неинтерактивном (CI) проект **не** создаётся молча — команда выдаёт ошибку и просит выполнить `lizard init --name ` (или передать `--name`). Это защищает от появления пустого проекта из-за опечатки. + + + +## Основные флаги + +| Флаг | Назначение | +|------|----------| +| `-s, --service ` | Выбрать/создать конкретный сервис | +| `--build-command ` | Переопределить команду сборки | +| `--start-command ` | Переопределить команду запуска | +| `--pre-deploy-command ` | Запустить один раз перед каждым деплоем (например, миграции) | +| `--port ` | Порт контейнера (`0` = [режим воркера](/deploy/workers)) | +| `--region ` | Регион для развертывания | +| `-d, --detach` | Запустить деплой и выйти без стриминга логов | +| `-c, --ci` | Вывод, дружественный к CI | +| `--no-gitignore` | Загрузить всё, игнорируя `.gitignore` | + +```bash +lizard up --service api --start-command "node server.js" --port 8080 +``` + + + +## Установка команд сборки и запуска + +Передача `--build-command` или `--start-command` переключает сервис на путь **синтезированного Dockerfile**. На этом пути `Procfile` и `package.json` `scripts.start` **не** считываются — задавайте команду запуска явно (или включите `CMD` в свой Dockerfile). Подробнее в разделе [Конвейер сборки](/concepts/build-pipeline). Чаще всего это касается Python: [Django, Flask и FastAPI](https://lizard.build/blog/python-app-hosting#deploying-django) требуют разную строку `gunicorn` или `uvicorn`. + + + +## Повторное развертывание upload-сервиса + +`lizard up` повторно загружает и пересобирает. Чтобы пересобрать **последнюю** загрузку с текущими переменными без повторной загрузки: + +```bash +lizard redeploy --service api +``` + +## Headless / CI + +Для неинтерактивных сценариев явно привяжите проект перед деплоем: + +```bash +export LIZARD_TOKEN=lzd_xxx +lizard init --name my-project +lizard up --ci --service api +``` + + + +## Когда лучше выбрать GitHub + +Загрузка отлично подходит для быстрой итерации и ситуаций без удалённого репозитория. Для всего долгоживущего предпочитайте [источник из GitHub](/deploy/github), чтобы пуши автоматически переразвертывали приложение и у вас была чистая история деплоев. + + + +## См. также + +- [`lizard up`](/cli/up) — полный справочник команд. +- [Конвейер сборки](/concepts/build-pipeline) — как определяется и собирается ваш стек. diff --git a/_locales/ru/deploy/workers.mdx b/_locales/ru/deploy/workers.mdx new file mode 100644 index 0000000..94f9a33 --- /dev/null +++ b/_locales/ru/deploy/workers.mdx @@ -0,0 +1,124 @@ +--- +description: "Запуск потребителей очередей и опросных циклов без HTTP-порта. Что меняет containerPort=0, как включить рабочий режим и когда не стоит." +--- + + + +# Фоновые обработчики + +Не каждый сервер обслуживает HTTP. Потребители очередей, реконсилеры, cron-опросные циклы и другие фоновые рабочие нагрузки не слушают порт — запустите их в **рабочем режиме**, установив порт контейнера в `0`. + + + +## Что меняет рабочий режим + +Когда `containerPort=0`, платформа: + +- **Пропускает внедрение `PORT`** — обработчик не привязывается нигде. +- **Пропускает проверку доступности порта** — нет спама `app port X unreachable` в логах и ложноположительного статуса "unhealthy". +- **Пропускает `EXPOSE`** в синтезируемом Dockerfile. +- **Пропускает регистрацию маршрута балансировщика** — ничего не обслуживается. (Сгенерированный домен `*.onlizard.com` может всё ещё отображаться в сервисе, но он не будет отвечать.) + + + +## Включить рабочий режим + +Три эквивалентных способа: + +```bash +# New upload-source worker +lizard up --port 0 + +# Flip an existing service +lizard port 0 --service worker + +# Via the config:apply path +lizard service set worker --set containerPort=0 +``` + +Рабочий режим — жёсткий переключатель — для вступления в силу изменения порта требуется повторный деплой. + + + +## Проверить текущий порт + +```bash +lizard port --service worker +``` + +Выводит текущий порт контейнера или `worker mode`, когда он `0`. + + + +## Когда *не* стоит использовать рабочий режим + +Не используйте рабочий режим для обычного HTTP-сервиса, который просто медленно запускается. Рабочий режим полностью отключает проверку доступности, поэтому он **скроет** ошибки вроде "the listener never came up". Если ваш сервис предназначен для обслуживания трафика, оставьте реальный порт и исправьте запуск. + + + +## Запуск потребителя очереди + +Используйте [пример redis-worker](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/redis-worker). Он перемещает задание из списка ожидающих в список обрабатываемых, сохраняет его результат в верхнем регистре и подтверждает задание в транзакции Redis. Оставьте одну реплику: восстановление при запуске предполагает одного потребителя. Пример использует Python 3.13 и redis-py 6.4.0. + +Из директории с его Dockerfile: + +```bash +lizard init --name queue-example +lizard add --service worker +lizard add redis +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +lizard up --service worker --port 0 +``` + +Выполните вход с помощью `lizard login`, если команда сообщает, что требуется аутентификация. Используйте фактическое имя базы данных, если оно не `redis`. Держите ссылку в кавычках. Установите её перед загрузкой приложения. В macOS с Lizard CLI 0.3.92 добавьте префикс `lizard up` с `COPYFILE_DISABLE=1`, чтобы исключить метаданные AppleDouble. + +Проверьте финальное событие деплоя, затем проверьте обработчик: + +```bash +lizard port --service worker +lizard logs --service worker --json +lizard ssh --service worker -- python jobs.py enqueue first-job +lizard ssh --service worker -- python jobs.py result first-job +``` + +Процесс выводит `Queue worker ready`. Если хвост лога пуст, переходите к проверке задания ниже; в [результатах тестов](/guides/validation) зафиксирован наблюдаемый лимит логирования. Команда результата ждёт до 30 секунд и выводит `{"id": "first-job", "result": "HELLO"}`. Само по себе запущенный процесс не доказывает, что он может потреблять задания. Managed Redis доступен изнутри сервиса; CLI-команде не требуется, чтобы ваш ноутбук достигал его приватного адреса. + + + +## Проверка перезапуска + +Для этого тестового сервиса перезапустите обработчик и отправьте ещё одно задание: + +```bash +lizard restart --service worker +lizard ssh --service worker -- python jobs.py result first-job +lizard ssh --service worker -- python jobs.py enqueue after-restart +lizard ssh --service worker -- python jobs.py result after-restart +``` + +Дождитесь возвращения сервиса в `running` в `lizard ps --json`, если SSH ещё недоступен. Оба результата должны быть `HELLO`. Первый результат живёт в Redis, поэтому перезапуск обработчика не удаляет его. При запуске единственный потребитель возвращает незавершённые записи обработки в список ожидающих. + +Этот демо принимает только JSON-задания, созданные `jobs.py`. Он не реализует очередь мёртвых писем, валидацию для недоверенных производителей или exactly-once внешние побочные эффекты. Для платежей, email или других эффектов используйте проверенную библиотеку очередей и идемпотентные обработчики. Надёжность и бэкап Redis отделены от поведения перезапуска обработчика; см. [хранилище и восстановление](/platform/storage-and-recovery). + + + +## Устранение неполадок + +| Симптом | Проверка | +|---|---| +| Сервис не найден | Выполните `lizard add --service worker` после создания проекта. | +| Нет `Queue worker ready` | Проверьте `REDIS_URL` сервиса, готовность аддона и ошибки подключения. Никогда не печатайте строку подключения. | +| Обработчик ожидает HTTP-порт | Установите `containerPort=0`; изменение на работающем сервисе требует повторного деплоя. | +| Нет результата через 30 секунд | Прочитайте логи обработчика и проверьте ID задания. Этот пример принимает задания только от своего `jobs.py`. | +| Дублирующиеся эффекты | Повторная попытка может выполнить работу снова. Этот пример сохраняет результат по ID задания; внешние эффекты требуют свою идемпотентность. | + + + +## См. также + +- [`lizard port`](/cli/port) — показать или изменить порт контейнера сервиса. +- [Сервис никогда не становится здоровым](/deploy/troubleshooting/service-never-healthy) — самая частая ошибка конфигурации рабочего режима. +- [Управляемые аддоны](/addons) — Redis, Postgres и S3 для стейтфул-нагрузок. +- [Хостинг Python-приложений](https://lizard.build/blog/python-app-hosting#deploying-django) — Celery-обработчик — тот же образ с другой командой и без HTTP-порта. + +См. [результаты сценарийных тестов](/guides/validation) для проверенных версий, облачных результатов и оставшихся ограничений. diff --git a/_locales/ru/framework-guides/_meta.ts b/_locales/ru/framework-guides/_meta.ts new file mode 100644 index 0000000..b3d091b --- /dev/null +++ b/_locales/ru/framework-guides/_meta.ts @@ -0,0 +1,16 @@ +export default { + index: "Обзор", + nextjs: { title: "Next.js", display: "children" }, + react: "React (Vite)", + vue: "Vue (Vite)", + astro: "Astro", + nuxt: "Nuxt", + sveltekit: "SvelteKit", + fastapi: "FastAPI", + django: "Django", + docusaurus: "Docusaurus", + vitepress: "VitePress", + hugo: "Hugo", + 'static-routing': "Статические маршруты и 404", + validation: "Проверенные версии и результаты", +}; diff --git a/_locales/ru/framework-guides/astro.mdx b/_locales/ru/framework-guides/astro.mdx new file mode 100644 index 0000000..d0b11c5 --- /dev/null +++ b/_locales/ru/framework-guides/astro.mdx @@ -0,0 +1,98 @@ +--- +description: "Разверните Astro на Lizard как статический сайт или с автономным адаптером Node. Настройте вывод, команды сборки, порты и проверки для серверных маршрутов и отсутствующих страниц." +--- + + + +# Развертывание Astro на Lizard + +Astro имеет два пути развертывания на Lizard: обслуживание статического каталога `dist/` на порту `80` или запуск автономного адаптера Node на порту `3000` для маршрутов по запросу. Выберите режим перед развертыванием, так как адаптер меняет и вывод, и среду выполнения. + + + +## Выбор режима + +| Режим | Конфигурация | Среда выполнения | Порт | +|---|---|---|---| +| Статический сайт | Статический вывод без серверного адаптера | nginx обслуживает `dist/` | `80` | +| Node-сервер | `@astrojs/node` в автономном режиме | `node ./dist/server/entry.mjs` | `3000` | + +Оба пути используют скрипт `build`, который запускает `astro build`. Закоммитьте файл блокировки и сохраните путь вывода `dist` по умолчанию. Определение считывает конфигурацию Astro и установленные зависимости. Неиспользуемая зависимость адаптера Node сама по себе не выбирает серверный путь. Используйте буквальные значения `output` и настройки адаптера; динамические значения, пользовательские пути вывода и режим посредника (middleware) требуют Dockerfile. + + + +## Настройка Node-сервера + +Для страниц по запросу добавьте версию адаптера Node, совместимую с вашей версией Astro: + +```bash +npx astro add node +``` + +Проверьте `astro.config.mjs`: + +```js +import { defineConfig } from 'astro/config'; +import node from '@astrojs/node'; + +export default defineConfig({ + output: 'server', + adapter: node({ mode: 'standalone' }), +}); +``` + +Автономный режим запускает собственный HTTP-сервер. Режим посредника требует отдельного сервера и не подходит для этой команды запуска. Ознакомьтесь с [руководством по адаптеру Astro Node](https://docs.astro.build/en/guides/integrations-guide/node/), если вам нужен посредник или смесь предварительно отрендеренных и по запросу маршрутов. + + + +## Локальное тестирование + +```bash +npm ci +npm run build +``` + +Для режима Node: + +```bash +HOST=0.0.0.0 PORT=3000 node ./dist/server/entry.mjs +``` + +Запросите маршрут, который действительно работает на сервере, и собранный ассет. Для статического сайта используйте `npm run preview` локально и проверьте сгенерированные файлы маршрутов в `dist/`. + + + +## Развертывание + +После [настройки CLI](/framework-guides#prepare-the-project) создайте проект: + +```bash +lizard init --name astro-app +lizard add --service web +``` + +Для адаптера Node: + +```bash +lizard up --service web --port 3000 +``` + +Для статического сайта: + +```bash +lizard up --service web --port 80 +``` + +Используйте только команду для выбранного режима. Оставьте переопределения команды сервиса не заданными для обнаружения lizardpack. Прочитайте `lizard logs --build --service web --json`, затем проверьте логи выполнения и живой URL. + + + +## Переменные, сессии и маршруты + +Значения, используемые для генерации статического HTML, требуют новой сборки при изменении. Серверный код может считывать переменные среды выполнения через механизмы, поддерживаемые вашей версией Astro; настройте их в [переменных и секретах](/variables). Значения, видимые в браузере, не должны содержать учётные данные. + +Если ваше приложение использует сессии, выберите хранилище, подходящее для перезапусков и множественных реплик. Не полагайтесь на файловую систему контейнера как на общее долговечное хранилище. См. [хранилище и восстановление](/platform/storage-and-recovery). + +Для сайта со статическим контентом протестируйте несуществующий URL и используйте [статические маршруты и 404](/framework-guides/static-routing) для возврата правильного статуса. Если развертывание SSR завершается или не обслуживает маршруты, убедитесь, что существует `dist/server/entry.mjs`, адаптер использует автономный режим, а порт сервиса — `3000`. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/framework-guides/django.mdx b/_locales/ru/framework-guides/django.mdx new file mode 100644 index 0000000..df8f447 --- /dev/null +++ b/_locales/ru/framework-guides/django.mdx @@ -0,0 +1,221 @@ +--- +description: "Развертывание Django на Lizard с Gunicorn, явным WSGI-модулем, портом 8000, продакшен-настройками, миграциями базы данных и планом для статических и загружаемых файлов." +--- + + + +# Развертывание Django на Lizard + +Запустите Django на Lizard с Gunicorn и WSGI-модулем вашего проекта на порту `8000`. Подготовьте продакшен-настройки, доступ к базе данных и раздачу статических файлов перед тем, как полагаться на развернутое приложение. `manage.py runserver` — это сервер разработки. + + + +## Задайте команду запуска + +В этом руководстве предполагается `manage.py`, `requirements.txt` и пакет проекта с именем `config`, содержащий `wsgi.py`. Замените `config` на фактическое имя вашего пакета. + +Включите Django, Gunicorn и драйвер базы данных, который использует ваше приложение, в проверенные зависимости. Добавьте `Procfile`: + +```text +web: gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +Явный модуль устраняет неоднозначность, когда настройки находятся во вложенных пакетах. ASGI-приложение с WebSockets требует ASGI-сервер и другую команду запуска; это руководство охватывает WSGI. + +| Настройка | Значение | +|---|---| +| Установка | `pip install -r requirements.txt` | +| Среда выполнения | Gunicorn с вашим WSGI-модулем | +| Порт сервиса | `8000` | +| Рабочая директория | Директория, содержащая `manage.py` | + + + +## Подготовьте продакшен-настройки + +Django ожидает словарь `DATABASES` в `settings.py`. Установка только `DATABASE_URL` на сервисе не подключает Django к PostgreSQL. Шаги ниже создают [Managed Postgres](/addons/postgres), передают его URL приложению и преобразуют этот URL в настройки подключения Django. + +Добавьте эти пакеты в `requirements.txt`, сохраняя любые другие зависимости, которые нужны вашему приложению. Это версии, используемые в [полном примере](https://github.com/lizard-build/docs/tree/main/_examples/django): + +```text +Django==6.1.1 +gunicorn==26.2.0 +whitenoise==6.12.0 +psycopg[binary]==3.3.5 +dj-database-url==3.1.2 +``` + +`psycopg` — драйвер PostgreSQL. `dj-database-url` считывает имя базы данных, пользователя, пароль, хост и порт из URL подключения. Замените соответствующие настройки в `settings.py` вашего проекта на этот блок; сохраните ваши существующие apps, middleware, шаблоны и другие настройки: + +```python +import os +from pathlib import Path + +import dj_database_url +from django.core.exceptions import ImproperlyConfigured + +BASE_DIR = Path(__file__).resolve().parent.parent + + +def required_env(name): + value = os.environ.get(name, "").strip() + if not value: + raise ImproperlyConfigured(f"Set the {name} environment variable.") + return value + + +def env_list(name): + values = [item.strip() for item in required_env(name).split(",") if item.strip()] + if not values: + raise ImproperlyConfigured(f"Set at least one value in {name}.") + return values + + +SECRET_KEY = required_env("SECRET_KEY") +debug_value = os.environ.get("DEBUG", "false").strip().lower() +if debug_value not in {"true", "false"}: + raise ImproperlyConfigured("DEBUG must be true or false.") +DEBUG = debug_value == "true" +ALLOWED_HOSTS = env_list("ALLOWED_HOSTS") +CSRF_TRUSTED_ORIGINS = env_list("CSRF_TRUSTED_ORIGINS") +DATABASES = { + "default": dj_database_url.parse( + required_env("DATABASE_URL"), + conn_max_age=60, + conn_health_checks=True, + ) +} +``` + +Не оставляйте более старые назначения `DATABASES`, `SECRET_KEY` или `DEBUG` ниже в файле: они заменят эти значения. Этот пример требует непустые значения `SECRET_KEY`, `DATABASE_URL`, `ALLOWED_HOSTS` и `CSRF_TRUSTED_ORIGINS`. Отсутствующие или пустые значения останавливают запуск с именем переменной. `DEBUG` по умолчанию `false`; установите его в `false` на развернутом сервисе. + +`ALLOWED_HOSTS` принимает хостнеймы через запятую без схемы и пути, например `app.example.com,www.example.com`. `CSRF_TRUSTED_ORIGINS` принимает origins через запятую со схемой, например `https://app.example.com`. Укажите порт для локальных origins, которые его используют. Пример требует явный список origins; сам Django допускает пустой список для приложений, не требующих дополнительных доверенных origins. Доверяйте только тем origins, которые должны отправлять формы в это приложение. Эти настройки не заменяют CSRF-токены. + +URL берутся из [секрета или ссылки](/variables) сервиса, а не из значения, закоммиченного в исходники. Не используйте локальный SQLite в контейнере как долговечную базу данных для развернутого приложения. См. [использование dj-database-url](https://pypi.org/project/dj-database-url/) для разбора URL и параметров подключения. + +С вашими локальными переменными окружения и доступным PostgreSQL выполните: + +```bash +python -m pip install -r requirements.txt +python manage.py check --deploy +gunicorn config.wsgi:application --bind 0.0.0.0:8000 +``` + +Просмотрите [чек-лист развертывания](https://docs.djangoproject.com/en/6.1/howto/deployment/checklist/) Django для настроек, актуальных для вашего приложения. Небольшой пример не настраивает каждую продакшен-настройку безопасности. Проверьте обработку прокси и HTTPS с реальным публичным URL перед включением защищённых cookie, HSTS или редиректов. Доверяйте переадресованным HTTPS-заголовкам только тогда, когда прокси ими управляет. + + + +## Спланируйте статические файлы и миграции + +Gunicorn один не раздаёт статические файлы Django. Выберите middleware для статических файлов, настроенный в приложении, или отдельный статический хост. Соберите ассеты в путь, который обслуживает эта настройка. Python-путь lizardpack на основе requirements не запускает автоматически `collectstatic`; добавьте его в полную сборку Dockerfile, когда приложению нужен этот шаг. + +Для WhiteNoise сохраняйте `django.contrib.staticfiles` в `INSTALLED_APPS` и вставьте `whitenoise.middleware.WhiteNoiseMiddleware` сразу после `SecurityMiddleware` Django. Добавьте или обновите эти настройки: + +```python +STATIC_URL = "/static/" +STATIC_ROOT = BASE_DIR / "staticfiles" +STORAGES = { + "default": {"BACKEND": "django.core.files.storage.FileSystemStorage"}, + "staticfiles": { + "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage", + }, +} +``` + +Сохраняйте ваш существующий бэкенд `STORAGES["default"]`, если приложение уже хранит загрузки в другом месте. WhiteNoise раздаёт собранные статические ассеты, не загрузки пользователей. + +Используйте этот Dockerfile в корне проекта: + +```dockerfile +FROM python:3.13-slim +WORKDIR /app +COPY requirements.txt ./ +RUN pip install --no-cache-dir -r requirements.txt +COPY . . +RUN SECRET_KEY=build-only-placeholder \ + DATABASE_URL=postgresql://build:build@127.0.0.1:1/build \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + python manage.py collectstatic --noinput +EXPOSE 8000 +CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"] +``` + +Значения в строке `RUN` существуют только для `collectstatic`. URL базы данных — это заполнитель, указывающий на неиспользуемый локальный порт; базы данных там не запускается. Загрузка настроек разбирает URL, но сбор ассетов не требует подключения к базе. Не запрашивайте базу данных из импортов модулей или `AppConfig.ready()`. Пример также передаёт `collectstatic` с отключённой сетью контейнера. + +Эти назначения не становятся переменными окружения runtime. Установите свежий `SECRET_KEY` и реальную ссылку на базу данных на сервисе перед запуском. Не передавайте продакшен-секреты в Docker-сборку. + +Создайте `.dockerignore` и исключите те же пути из [загрузки исходников](/cli/up): + +```text +.env* +.venv/ +venv/ +.git/ +__pycache__/ +*.pyc +*.sqlite3 +staticfiles/ +``` + +Храните загрузки пользователей в долговечном хранилище, таком как [Managed Object Storage](/addons/storage), а не в статической директории контейнера. Ознакомьтесь с [хранилищем и восстановлением](/platform/storage-and-recovery). + +Относитесь к миграциям базы данных как к отдельному шагу релиза. Сделайте бэкап данных при необходимости, обеспечьте безопасность повторного запуска миграций и примените их до того, как запросы потребуют новую схему. Pre-deploy-команда не заменяет проверку поведения при конкуренции и сбоях. + + + +## Разверните и проверьте + +После [настройки CLI](/framework-guides#prepare-the-project) подключите [GitHub-сервис](/deploy/github), настройте его секреты и продакшен-настройки, и разверните с контейнерным портом `8000`. Для нового проекта на основе загрузки: + +```bash +lizard init --name django-app +lizard add --service web +``` + +Создайте [Managed Postgres](/addons/postgres) в этом проекте. Если у вас уже есть экземпляр, пропустите `add postgres` и используйте его имя в ссылке: + +```bash +lizard add postgres --name postgres +``` + +Задайте [секреты сервиса](/cli/secrets) приложения. `postgres` в `${{postgres.DATABASE_URL}}` именует сервис базы данных, не псевдоним базы Django. Lizard разрешает [ссылку](/variables/references) во время деплоя и внедряет получившийся URL в процесс `web`. Одинарные кавычки не дают оболочке раскрыть ссылку. Блок `settings.py` выше затем превращает URL в `DATABASES["default"]`. + +```bash +DJANGO_SECRET_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(48))')" +lizard secrets set SECRET_KEY="$DJANGO_SECRET_KEY" \ + DATABASE_URL='${{postgres.DATABASE_URL}}' DEBUG=false \ + ALLOWED_HOSTS=localhost CSRF_TRUSTED_ORIGINS=http://localhost \ + --service web +lizard up --service web --port 8000 +lizard ps --json +``` + +`localhost` — временная настройка хоста, позволяющая процессу запуститься, пока вы получаете его публичный хостнейм; публичные запросы вернут 400. Если вы уже знаете хостнейм, задайте его перед первой загрузкой. Иначе замените эти плейсхолдеры на хостнейм и HTTPS-origin, возвращённые для вашего сервиса: + +```bash +lizard secrets set ALLOWED_HOSTS=YOUR_PUBLIC_HOST \ + CSRF_TRUSTED_ORIGINS=https://YOUR_PUBLIC_HOST --service web +``` + +Отсутствующая цель ссылки или ключ могут разрешиться в пустую строку. Проверка обязательного значения тогда остановит Django с `Set the DATABASE_URL environment variable.` Проверьте имя сервиса базы данных и его ключ `DATABASE_URL`; не выводите URL подключения в логи. + +Изменение переменной перезапускает процесс. Исключите локальные виртуальные окружения, секреты и локальные базы данных из загрузок. После запуска процесса примените миграции: + +```bash +lizard ssh --service web -- python manage.py migrate --noinput +``` + +Запустите команду снова, чтобы убедиться, что миграций не осталось. Не считайте успешную проверку порта доказательством существования таблиц. + +Проверьте URL приложения, страницу с базой данных, отправку формы и статический ассет. Если приложение использует Django admin, также проверьте его CSS. Читайте `lizard logs --service web --json` для ошибок импорта или настроек. Ответ 400 часто означает, что `ALLOWED_HOSTS` неверен; отсутствующий CSS обычно означает, что статические ассеты не были собраны или не раздаются. Проверьте фактическую ошибку перед изменением настроек. + +См. [проверенные версии и облачные результаты](/framework-guides/validation) для проверок деплоя 9 сентября 2026 года и их ограничений. + + + + +## Воспроизведите этот пример + +[Пример Django](https://github.com/lizard-build/docs/tree/main/_examples/django) включает настройки, Dockerfile, requirements, форму с базой данных и тест-раннер. Скопируйте его в отдельную директорию и запустите `python3 tests/verify.py` с работающим Docker. Он соберёт образ, запустит локальный PostgreSQL, проверит миграции и HTTP-поведение, и остановит свои тестовые контейнеры. Он не создаёт сервисы Lizard. См. его README для проверок и сохраняемых Docker-ресурсов. + +Проверка 14 сентября 2026 года охватывает этот обновлённый пример в локальных Linux-контейнерах. Ранние облачные результаты, на которые ссылаются выше, касаются руководства от 9 сентября; обновлённые настройки ещё не проходили новый облачный деплой. diff --git a/_locales/ru/framework-guides/docusaurus.mdx b/_locales/ru/framework-guides/docusaurus.mdx new file mode 100644 index 0000000..ef2b66a --- /dev/null +++ b/_locales/ru/framework-guides/docusaurus.mdx @@ -0,0 +1,88 @@ +--- +description: "Разверните Docusaurus на Lizard как статический сайт документации. Соберите каталог build, задайте url и baseUrl, используйте порт 80 и проверьте прямые переходы и настоящие 404." +--- + + + +# Развертывание Docusaurus на Lizard + +Соберите Docusaurus на Lizard и раздавайте сгенерированный каталог `build/` через nginx на порту `80`. Продакшн-развертывание отдаёт статические файлы; оно не запускает сервер разработки `docusaurus start`. + +Начните с [полного примера исходного кода](https://github.com/lizard-build/docs/tree/main/_examples/docusaurus), который включает конфигурацию и файлы, используемые в этом рецепте. + + + +## Подготовка сайта + +Выполните из каталога Docusaurus, содержащего `package.json`, его lock-файл и `docusaurus.config.*`. Оставьте `@docusaurus/core` в зависимостях и скрипт сборки, запускающий `docusaurus build`. + +| Параметр | Значение | +|---|---| +| Сборка | `npm run build` | +| Вывод | `build/` | +| Среда выполнения | nginx | +| Порт сервиса | `80` | + +Задайте `url` в конфигурации Docusaurus как предполагаемый публичный адрес сайта, а `baseUrl` — как путь, по которому он будет работать. Для сайта в корне домена `baseUrl` равен `/`. Как только вы узнаете окончательное имя хоста, пересоберите с этим хостом, чтобы сгенерированные канонические URL и записи в карте сайта использовали его. + +Выберите единую политику слеша в конце URL и проверьте полученные файлы. Оставьте каталог вывода по умолчанию, если не используете Dockerfile, копирующий ваш собственный каталог. [Руководство по развертыванию Docusaurus](https://docusaurus.io/docs/deployment) объясняет эти настройки фреймворка. + + + +## Локальная сборка и проверка + +```bash +npm ci +npm run build +npm run serve +``` + +Последняя команда предполагает, что в вашем проекте есть скрипт `serve` из шаблона. Проверьте главную страницу, вложенную страницу документации, изображение и страницу версии, если используете версионирование документов. Исправьте битые ссылки, о которых сообщает сборка, перед развертыванием. + + + +## Развертывание + +После [настройки CLI](/framework-guides#prepare-the-project): + +```bash +lizard init --name docusaurus-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Если используете сгенерированное имя хоста, прочитайте его после первого развертывания: + +```bash +lizard service show web --json +``` + +Задайте `url` в `docusaurus.config.js` этому имени хоста: + +```js +url: 'https://YOUR_PUBLIC_HOST', +``` + +Загрузите изменённую конфигурацию, чтобы сборка использовала публичный URL: + +```bash +lizard up --service web --port 80 +``` + + +Закоммитьте исходный код, плагины, конфигурацию и lock-файл. Исключите файлы `node_modules/`, `build/`, `.docusaurus/` и `.env` из загрузки. Оставьте переопределения команды сервиса не заданными, чтобы использовался путь автоопределения Docusaurus. + + + +## Обслуживание внутренних маршрутов и отсутствующих страниц + +Новые сборки Docusaurus отдают сгенерированные файлы маршрутов и возвращают HTTP 404 для неизвестных путей. Пользовательский Dockerfile для этой политики маршрутизации не требуется. Если ваш сервис всё ещё использует образ, собранный до исправления маршрутизации от сентября 2026 года, пересоберите его. Используйте [статические маршруты и 404](/framework-guides/static-routing) только когда нужен пользовательский nginx-поведение. + +После развертывания запросите напрямую вложенный URL документации, обновите страницу и проверьте статус несуществующего URL. Также проверьте канонический URL и карту сайта на конечном имени хоста. Видимая страница ошибки с HTTP 200 всё равно является мягким 404. + +Если ресурсы отсутствуют, сравните их URL с `baseUrl`. Если внутренний маршрут возвращает главную страницу, изучите структуру сгенерированных файлов и правила nginx. Если после изменения переменной окружения или Markdown-файла остаётся старый контент, убедитесь, что новая сборка действительно завершилась; статический HTML меняется только при сборке. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 года и их ограничений. + diff --git a/_locales/ru/framework-guides/fastapi.mdx b/_locales/ru/framework-guides/fastapi.mdx new file mode 100644 index 0000000..d094ea7 --- /dev/null +++ b/_locales/ru/framework-guides/fastapi.mdx @@ -0,0 +1,98 @@ +--- +description: "Развертывание FastAPI на Lizard с Uvicorn, requirements.txt, Procfile и портом 8000. Проверка эндпоинта здоровья и диагностика ошибок импорта, хоста и зависимостей." +--- + + + +# Развертывание FastAPI на Lizard + +Запустите FastAPI на Lizard с Uvicorn, прослушивающим `0.0.0.0:8000`. Включите и FastAPI, и Uvicorn в зависимости приложения. Импорт файла, объявляющего `app = FastAPI()`, сам по себе не запускает HTTP-сервер. + + + +## Пример проекта + +[Пример FastAPI](https://github.com/lizard-build/fastapi-example) включает приложение, Procfile, закреплённые зависимости, лицензию MIT и HTTP-тесты. Его CI запускает производственную точку входа Uvicorn на Linux. Мы также развернули коммит `df522c1` с GitHub и проверили health, OpenAPI, интерактивную документацию, эхо JSON, невалидный ввод и отсутствующий маршрут через публичный HTTPS 09.09.2026. + + + +## Подготовка приложения + +В этом примере используются `requirements.txt` и `main.py` в корне приложения: + +```python +from fastapi import FastAPI + +app = FastAPI() + +@app.get("/health") +def health(): + return {"status": "ok"} +``` + +Добавьте `fastapi` и `uvicorn` в рабочий процесс зависимостей и сохраните проверенные, разрешённые версии в `requirements.txt`. Выберите минорную версию Python в `.python-version`, например `3.13`, если ваши зависимости это поддерживают. + +Создайте `Procfile` с явной целью импорта: + +```text +web: uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +`main:app` означает объект `app` в `main.py`. Для `src/api.py` используйте путь импорта, работающий из корня приложения, например `src.api:app`. Явный Procfile избавляет от зависимости от обнаружения паттернов исходного кода в пользовательских компоновках. + +| Настройка | Значение | +|---|---| +| Установка | `pip install -r requirements.txt` | +| Запуск | команда Procfile `web:` | +| Порт сервиса | `8000` | +| Результат сборки | Исходный код Python и установленные зависимости | + + + +## Локальное тестирование + +Используйте локальное виртуальное окружение: + +```bash +python -m venv .venv +source .venv/bin/activate +pip install -r requirements.txt +uvicorn main:app --host 0.0.0.0 --port 8000 +``` + +В другом терминале: + +```bash +curl --fail http://localhost:8000/health +``` + +Ожидается успешный ответ, содержащий `{"status":"ok"}`. Оставьте режим перезагрузки для разработки. [Руководство по серверу FastAPI](https://fastapi.tiangolo.com/deployment/manually/) объясняет ASGI-сервер и цель импорта. + + + +## Развертывание + +После [настройки CLI](/framework-guides#prepare-the-project) загрузите из корня приложения: + +```bash +lizard init --name fastapi-app +lizard add --service api +lizard up --service api --port 8000 +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +Исключите файлы `.venv/`, `__pycache__/` и `.env`. Оставьте переопределения сборки/запуска сервиса неустановленными, чтобы lizardpack читал Procfile. Путь на основе requirements здесь не требует отдельной команды компиляции. + +Запросите `/health` на возвращённом HTTPS URL, затем протестируйте реальное действие API. TCP-проба здоровья лишь подтверждает, что процесс открыл порт; ваш эндпоинт здоровья может добавлять проверки, важные для приложения. + + + +## Данные и частые ошибки + +Задайте учётные данные через [переменные и секреты](/variables). Добавьте [Managed Postgres](/addons/postgres), когда приложению нужна база данных, и используйте ссылку на соединение в области сервиса. Файлы, локальные для контейнера, не являются долговечным хранилищем приложения; см. [хранилище и восстановление](/platform/storage-and-recovery). + +При `No module named uvicorn` проверьте установленные требования. При ошибке ASGI-импорта выполните точную команду Procfile локально из того же корня. Если сервис никогда не становится работоспособным, проверьте порт `8000` и хост привязки. Если процесс завершается без логов сервера, убедитесь, что он запускает Uvicorn, а не просто `python main.py`. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/framework-guides/hugo.mdx b/_locales/ru/framework-guides/hugo.mdx new file mode 100644 index 0000000..8e767f0 --- /dev/null +++ b/_locales/ru/framework-guides/hugo.mdx @@ -0,0 +1,89 @@ +--- +description: "Разверните Hugo на Lizard: соберите public с hugo --minify и обслуживайте на порту 80. Проверьте автоопределение, темы, baseURL, сгенерированные маршруты и статус несуществующих страниц." +--- + + + +# Развертывание Hugo на Lizard + +Lizard может собрать исходный сайт Hugo с помощью `hugo --minify` и обслуживать `public/` через nginx на порту `80`. Начните с исходной директории Hugo, с конфигурацией Hugo и `content/`, а не только загружая сгенерированный HTML. + +Начните с [полного примера исходного кода](https://github.com/lizard-build/docs/tree/main/_examples/hugo), который включает конфигурацию и файлы, используемые в этом рецепте. + + + +## Подготовка исходного кода + +Включите вашу конфигурацию Hugo, контент, макеты, ресурсы и все файлы темы, необходимые для сборки. Детектор Hugo ищет конфигурацию, такую как `hugo.toml`, `hugo.yaml` или `config/_default/`, а также директорию `content/`. + +| Настройка | Значение | +|---|---| +| Сборка | `hugo --minify` | +| Вывод | `public/` | +| Продакшн-сервер | nginx | +| Порт сервиса | `80` | + +Установите `baseURL` в предполагаемый публичный URL сайта, включая завершающий слеш. Пересоберите после назначения другого хостнейма, чтобы ссылки и сгенерированные записи карты сайта использовали его. Ознакомьтесь с [руководством Hugo по сборке и выводу](https://gohugo.io/getting-started/usage/). + + + +## Проверка зависимостей сборки + +Образ сборки Hugo по умолчанию — `hugomods/hugo:base`; он не закрепляет версию Hugo для вашего проекта. Если теме требуется конкретная версия Hugo, расширенное издание или инструменты Node, используйте полный Dockerfile с этими зависимостями и версией, которую вы тестировали. + +Конфигурация Hugo и `content/` выбирают сборщик Hugo до определения Go или Node. Проекты Hugo Modules с `go.mod` используют образ сборки с поддержкой Go. Наличие `package.json` останавливает сборку с просьбой предоставить Dockerfile: установите зависимости Node, соберите ресурсы, затем запустите `hugo --minify`. См. [порядок принятия решения о сборке](/concepts/build-pipeline#build-decision-order). + + + +## Локальная сборка и развертывание + +```bash +hugo --minify +hugo server +``` + +Ознакомьтесь с `public/` после первой команды. Используйте локальный сервер для проверки контента и рендеринга темы; `hugo server` — это не продакшн-команда запуска. + +После [настройки CLI](/framework-guides#prepare-the-project) разверните исходную директорию: + +```bash +lizard init --name hugo-site +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Если вы используете сгенерированный хостнейм, прочитайте его после первого развертывания: + +```bash +lizard service show web --json +``` + +Установите `baseURL` в `hugo.toml` на этот хостнейм: + +```toml +baseURL = "https://YOUR_PUBLIC_HOST/" +``` + +Загрузите изменённую конфигурацию, чтобы сборка использовала публичный URL: + +```bash +lizard up --service web --port 80 +``` + + +Исключите локальный сгенерированный вывод и секреты. При загрузке убедитесь, что исходные файлы темы действительно существуют в отправляемой директории; удалённая ссылка на подмодуль сама по себе не является контентом темы. + + + +## Проверка развернутого сайта + +Откройте домашнюю страницу, внутреннюю статью и изображение. Проверьте сгенерированные канонические URL и `sitemap.xml`. Протестируйте HTTP-статус вымышленного пути. Новые сборки Hugo обслуживают сгенерированный HTML и возвращают HTTP 404 для отсутствующих страниц. Для простой структуры исходников из этого руководства не нужен собственный Dockerfile. Пересоберите старые образы, чтобы получить актуальные правила маршрутизации. + +Используйте [статические маршруты и 404](/framework-guides/static-routing), если вам нужна собственная политика nginx. Пользовательская стадия сборки Hugo должна включать требуемую темой версию Hugo и инструменты, запустить `hugo --minify` и скопировать `public/` в образ обслуживания. + +Если ресурсы темы отсутствуют, изучите логи сборки, исходники темы и `baseURL`. Если запускается не тот сборщик, проверьте, что конфигурация Hugo и `content/` находятся в корне загрузки, и изучите существующие переопределения сервиса. Hugo производит статические файлы, поэтому изменения контента требуют новой сборки. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развёртывания от 9 сентября 2026 года и их ограничений. + diff --git a/_locales/ru/framework-guides/index.mdx b/_locales/ru/framework-guides/index.mdx new file mode 100644 index 0000000..cafd609 --- /dev/null +++ b/_locales/ru/framework-guides/index.mdx @@ -0,0 +1,69 @@ +--- +description: "Разверните Next.js, React, Vue, Astro, Nuxt, SvelteKit, FastAPI, Django, Docusaurus, VitePress и Hugo на Lizard. Найдите команды сборки, адаптеры, порты и проверки." +--- + + + +# Руководства по фреймворкам + +Разверните приложение на фреймворке на Lizard из исходного кода. Выберите свой фреймворк и режим рендеринга ниже, подготовьте его production-сборку, затем разверните с помощью Lizard CLI или подключите репозиторий GitHub. Серверные приложения запускают процесс; статические сайты отдают сгенерированные файлы через nginx. + + + +## Выберите фреймворк + +Эти настройки описывают стандартную структуру проектов в связанных руководствах. Команды подразумевают npm для JavaScript-проектов. Пользовательские пути вывода, адаптеры и переопределения сборки могут изменить результат. + +| Фреймворк | Сборка | Среда выполнения или вывод | Порт сервиса | +|---|---|---|---| +| [Next.js](/framework-guides/nextjs) | `npm run build` | `next start` через скрипт start | `3000` | +| [Статический экспорт Next.js](/framework-guides/nextjs/static-export) | `npm run build` | `out/` через Dockerfile | `80` | +| [React с Vite](/framework-guides/react) | `npm run build` | `dist/` | `80` | +| [Vue с Vite](/framework-guides/vue) | `npm run build` | `dist/` | `80` | +| [Astro](/framework-guides/astro) | `npm run build` | `dist/` или автономный Node-адаптер | `80` статический; `3000` сервер | +| [Nuxt](/framework-guides/nuxt) | `npm run build` | `node .output/server/index.mjs` | `3000` | +| [SvelteKit](/framework-guides/sveltekit) | `npm run build` | `node build` с adapter-node | `3000` | +| [FastAPI](/framework-guides/fastapi) | Установка Python-зависимостей | `uvicorn main:app --host 0.0.0.0 --port 8000` | `8000` | +| [Django](/framework-guides/django) | Установка Python-зависимостей | Gunicorn с вашим WSGI-модулем | `8000` | +| [Docusaurus](/framework-guides/docusaurus) | `npm run build` | `build/` | `80` | +| [VitePress](/framework-guides/vitepress) | `npm run docs:build` | `docs/.vitepress/dist/` в этом руководстве | `80` | +| [Hugo](/framework-guides/hugo) | `hugo --minify` | `public/` | `80` | + + + +## Подготовка проекта + +Выполняйте команды из директории приложения. Закоммитьте исходные файлы, конфигурацию и lockfile пакетов. Исключите `.env`, локальные зависимости и локальные артефакты сборки из загрузки. Node-проекты могут выбрать мажорную версию Node в `.nvmrc`; текущее значение по умолчанию — `22`. Это выбирает мажорную версию, а не конкретный патч-релиз. + +Установите Lizard CLI и войдите один раз: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +В каждом руководстве используется новый проект и сервис с именем `web` или `api`. Создайте этот сервис с помощью `lizard add --service web` (или `api`) перед первым вызовом `lizard up --service`. `up --service` выбирает существующий сервис; он не создает отсутствующий именованный сервис. Для существующего проекта проверьте `lizard status --json` и `lizard ps --json` перед развертыванием. Порт должен совпадать с процессом внутри контейнера, который должен слушать на `0.0.0.0`. + +Lizard CLI 0.3.95 исключает метаданные архивов macOS при загрузке. Настройка `COPYFILE_DISABLE` не нужна. Обновите старые версии CLI перед использованием этих руководств. + + + +## Выбор GitHub или локального источника + +Команды в руководствах используют `lizard up` для загрузки текущей папки. Эта команда меняет существующий сервис на загрузку исходного кода. Чтобы сохранить git push to deploy, [подключите GitHub](/deploy/github) и используйте настройки сборки из руководства в репозитории. Настройте порт сервиса из таблицы. + + + +## Согласованность настроек сборки + +В этих руководствах используется определение через lizardpack, если не требуется Dockerfile. Существующие `buildCommand` или `startCommand` имеют приоритет над определением и Dockerfile репозитория. Проверьте [порядок решений о сборке](/concepts/build-pipeline#build-decision-order) перед сменой метода сборки. Задайте скрипты в `package.json`, когда об этом сказано в руководстве; добавление CLI-переопределения — это другой путь сборки. + + + +## Проверка релиза + +Читайте логи сборки, логи рантайма и активный URL. Проверьте внутренний маршрут, отсутствующий маршрут и любые API или form action. Процесс, открывший свой порт, может все равно отдавать сломанную страницу. Для сгенерированных сайтов используйте [статические маршруты и 404](/framework-guides/static-routing), чтобы не возвращать главную страницу с HTTP 200 для любого неизвестного URL. + +Поддержка рантайма не подразумевает общие кэши, постоянные локальные файлы или каждую версию фреймворка. См. [ограничения](/platform/limits), [хранилище и восстановление](/platform/storage-and-recovery) и [известные проблемы](/platform/known-issues), когда ваше приложение полагается на эти функции. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/framework-guides/nextjs/_meta.ts b/_locales/ru/framework-guides/nextjs/_meta.ts new file mode 100644 index 0000000..b289a63 --- /dev/null +++ b/_locales/ru/framework-guides/nextjs/_meta.ts @@ -0,0 +1,4 @@ +export default { + index: "Next.js", + 'static-export': { title: "Статический экспорт", display: "скрыто" }, +}; diff --git a/_locales/ru/framework-guides/nextjs/index.mdx b/_locales/ru/framework-guides/nextjs/index.mdx new file mode 100644 index 0000000..1a05cb5 --- /dev/null +++ b/_locales/ru/framework-guides/nextjs/index.mdx @@ -0,0 +1,95 @@ +--- +description: "Развёртывание Next.js на Lizard как Node.js-сервер. Настройка next build, next start, порт 3000, переменные окружения и проверки страниц, API и Server Actions." +--- + + + +# Развёртывание Next.js на Lizard + +Запустите Next.js на Lizard как Node.js-сервер с `next build` и `next start`. Этот путь сохраняет сервер доступным для рендеринга во время запроса, Route Handlers и Server Actions. Если все маршруты можно построить заранее, следуйте [статическому экспорту Next.js](/framework-guides/nextjs/static-export). + + + +## Настройки сборки + +| Параметр | Значение | +|---|---| +| Корень проекта | Директория, содержащая `package.json` и конфигурацию Next.js | +| Скрипт сборки | `next build` | +| Скрипт запуска | `next start --hostname 0.0.0.0 --port 3000` | +| Результат сборки | `.next/` | +| Порт сервиса | `3000` | +| Среда выполнения | Node.js | + + + +## Подготовка приложения + +Сохраните `next`, `react` и `react-dom` в зависимостях и закоммитьте lockfile. Добавьте эти скрипты в `package.json`: + +```json +{ + "scripts": { + "dev": "next dev", + "build": "next build", + "start": "next start --hostname 0.0.0.0 --port 3000" + } +} +``` + +Используйте стандартный вывод Next.js для данного руководства. `output: 'export'` требует статический сервер, а `output: 'standalone'` нуждается в собственном запуске `server.js` и структуре ассетов. Ни один из них не использует этот рецепт `next start` без изменений. + +Выберите поддерживаемую основную версию Node в `.nvmrc`, например `22`. Исключите `.next/`, `node_modules/` и `.env*` из загружаемых исходников; при необходимости сохраните пример файла окружения без секретов. + + + +## Локальная проверка продакшн-сборки + +```bash +npm ci +npm run build +npm run start +``` + +В другом терминале откройте `http://localhost:3000` и проверьте внутренний маршрут. Если в приложении есть API или Server Действие, проверьте и их. Прохождение проверки сервера разработки не доказывает работоспособность продакшн-сборки. + + + +## Развёртывание + +После [установки Lizard CLI и входа](/framework-guides#prepare-the-project) выполните из директории приложения: + +```bash +lizard init --name nextjs-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Lizard обнаруживает зависимость `next` и запускает скрипты сборки и запуска. Эти команды подразумевают, что у сервиса нет существующих переопределений сборки или запуска. Используйте URL из вывода деплоя для повторной проверки, как локально. + + + +## Переменные окружения и данные + +Значения `NEXT_PUBLIC_*` становятся частью браузерного бандла во время сборки. Держите учётные данные в переменных только для сервера и настройте их для сервиса через [переменные и секреты](/variables). Код, который получает данные во время сборки, также должен иметь доступ к этим данным на этапе сборки. Перезапуск в runtime не изменяет уже сгенерированный HTML или JavaScript. + +Локальные файлы кэша и загруженные файлы не образуют общее хранилище между репликами. Проверьте требования Next.js к кэшу и Server Actions перед масштабированием свыше одной реплики. Храните долгие данные приложения в базе данных или объектном хранилище, и ознакомьтесь с [хранилищем и восстановлением](/platform/storage-and-recovery). + + + +## Устранение неполадок + +| Симптом | Проверка | +|---|---| +| `Missing script: start` | Добавьте продакшн-скрипт запуска выше; `next dev` предназначен для локальной разработки. | +| Приложение никогда не становится здоровым | Сопоставьте `--port 3000` со скриптом запуска и привяжитесь к `0.0.0.0`. | +| Публичный URL API всё ещё имеет старое значение | Пересоберите с новым значением `NEXT_PUBLIC_*`. | +| Сборка не может подключиться к базе данных | Проверьте, не обращается ли какой-то маршрут к данным во время сборки, и доступна ли эта зависимость на этом этапе. | +| Статический экспорт завершается с ошибкой под `next start` | Следуйте отдельному руководству по статическому экспорту. | + +[Руководство Next.js по самостоятельному хостингу](https://nextjs.org/docs/app/guides/self-hosting) охватывает поведение кэша на уровне фреймворка, изображений и работы с несколькими инстансами. При ошибках деплоя см. [сервис никогда не становится работоспособным](/deploy/troubleshooting/service-never-healthy). + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок деплоя от 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/framework-guides/nextjs/static-export.mdx b/_locales/ru/framework-guides/nextjs/static-export.mdx new file mode 100644 index 0000000..eca73a1 --- /dev/null +++ b/_locales/ru/framework-guides/nextjs/static-export.mdx @@ -0,0 +1,106 @@ +--- +description: "Разверните статический экспорт Next.js на Lizard с output export, Dockerfile для nginx, портом 80 и реальными ответами 404. Узнайте, для каких функций всё ещё нужен сервер Node.js." +--- + + + +# Развертывание статического экспорта Next.js + +Статический экспорт Next.js создаёт HTML, JavaScript и ресурсы в `out/`. Разверните эту директорию на Lizard с Dockerfile для nginx. Используйте этот путь для страниц, которые можно собрать заранее; для функций, нужных во время запроса, см. [руководство по серверу Node.js](/framework-guides/nextjs). + + + +## Настройка экспорта + +Добавьте эти параметры в `next.config.mjs`: + +```js +/** @type {import('next').NextConfig} */ +const nextConfig = { + output: 'export', + trailingSlash: true, + images: { unoptimized: true }, +}; + +export default nextConfig; +``` + +Оставьте `"build": "next build"` в `package.json`. В этом примере используются обычные экспортированные изображения; внешний загрузчик изображений — другой вариант. Сгенерируйте все необходимые параметры динамических маршрутов во время сборки. Cookies во время запроса, Server Actions и другие функции, требующие запущенный сервер Next.js, не будут работать в этом статическом контейнере. Сверьте используемые функции приложения со [справочником по статическому экспорту Next.js](https://nextjs.org/docs/app/guides/static-exports). + + + +## Добавьте полный Dockerfile + +Путь автоопределения Next.js рассчитан на сервер Node. Он не переключается на nginx только из‑за того, что конфигурация экспортирует `out/`. Добавьте этот Dockerfile в корень приложения; он предполагает наличие npm и закоммиченного `package-lock.json`: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +RUN npm run build + +FROM nginx:alpine +COPY --from=build /app/out /usr/share/nginx/html +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +Создайте `nginx.conf` рядом с ним: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + location / { + try_files $uri $uri/ =404; + } + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +Экспорт с trailing-slash создаёт директории маршрутов с `index.html`. Правило nginx отдаёт эти директории и возвращает HTTP 404 для отсутствующих путей. Добавьте `node_modules`, `.next`, `out`, `.git` и `.env*` в `.dockerignore` и исключите локальные файлы сборки из загрузки. + + + +## Сборка и развертывание + +```bash +npm ci +npm run build +``` + +Проверьте, что существуют `out/index.html` и ожидаемый внутренний маршрут. Если Docker доступен, протестируйте настоящий сервер локально: + +```bash +docker build -t nextjs-static . +docker run --rm -p 8080:80 nextjs-static +``` + +После [настройки CLI](/framework-guides#prepare-the-project) разверните в новый сервис: + +```bash +lizard init --name nextjs-static +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Полный Dockerfile включает шаг npm‑сборки, который может распознать lizardpack. Для существующего сервиса проверьте и удалите конфликтующие переопределения build/start перед выбором Dockerfile; см. [порядок решения о сборке](/concepts/build-pipeline#build-decision-order). + + + +## Проверка маршрутов и обновлений + +Запросите главную страницу, экспортированный внутренний маршрут, JavaScript‑ресурс и несуществующий путь. Несуществующий путь должен вернуть HTTP 404, а не главную страницу с HTTP 200. Используйте проверки из [статические маршруты и 404](/framework-guides/static-routing#verify-http-responses). + +Все изменения экспортированного контента требуют новой сборки. Переменные окружения во время выполнения не могут изменить значения, уже записанные в `out/`. Для публичных переменных сборки в пользовательском Dockerfile объявляйте нужные `ARG` до `RUN npm run build`; никогда не помещайте приватные учётные данные в экспортируемый пакет. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/framework-guides/nuxt.mdx b/_locales/ru/framework-guides/nuxt.mdx new file mode 100644 index 0000000..1d7501e --- /dev/null +++ b/_locales/ru/framework-guides/nuxt.mdx @@ -0,0 +1,109 @@ +--- +description: "Разверните Nuxt на Lizard с пресетом Nitro node-server. Добавьте продакшн-скрипт запуска, запустите сгенерированный сервер на порту 3000 и проверьте маршруты и runtime config." +--- + + + +# Развертывание Nuxt на Lizard + +Запустите Nuxt на Lizard с пресетом `node-server` от Nitro. Сборка создаёт `.output/server/index.mjs`, а процесс Node.js обслуживает страницы и серверные маршруты на порту `3000`. Для сгенерированного сайта на порту `80` используйте рецепт для статических сайтов ниже. + + + +## Настройка продакшн-сборки + +Используйте актуальный Lizard CLI из раздела [Подготовка проекта](/framework-guides#prepare-the-project). Версия 0.3.95 исключает метаданные macOS-архивов при загрузке. Если старый CLI сообщает об ошибке маршрута `._*.ts`, обновите CLI и загрузите снова. + +Установите пресет в `nuxt.config.ts`: + +```ts +export default defineNuxtConfig({ + nitro: { preset: 'node-server' }, +}); +``` + +Объедините эти скрипты в `package.json`, сохраняя остальные скрипты, необходимые вашему приложению: + +```json +{ + "scripts": { + "dev": "nuxt dev", + "build": "nuxt build", + "start": "HOST=0.0.0.0 PORT=3000 node .output/server/index.mjs" + } +} +``` + +Скрипт запуска использует оболочку Linux в контейнере развертывания. lizardpack определяет зависимость `nuxt` и запускает скрипты сборки и запуска. В новом проекте Nuxt может не быть `start`; добавьте его вместо того, чтобы полагаться на то, что `nuxt dev` обслужит продакшн-сборку. + +| Настройка | Значение | +|---|---| +| Сборка | `npm run build` | +| Точка входа сервера | `.output/server/index.mjs` | +| Запуск | `npm run start` | +| Порт сервиса | `3000` | + + + +## Проверка собранного приложения + +```bash +npm ci +npm run build +npm run start +``` + +Откройте `http://localhost:3000`, запросите внутреннюю страницу напрямую и вызовите один из ваших маршрутов `server/api`, если они есть. Убедитесь, что отчёт сборки указывает на пресет Node-сервера. Пресет Nitro для конкретного провайдера может создать другую точку входа. + + + +## Развертывание + +После [настройки CLI](/framework-guides#prepare-the-project) выполните из каталога Nuxt-приложения: + +```bash +lizard init --name nuxt-app +lizard add --service web +lizard up --service web --port 3000 +lizard logs --build --service web --json +lizard logs --service web --json +lizard ps --json +``` + +Не включайте в загрузку файлы `.nuxt/`, `.output/`, `node_modules/` и `.env`. Включайте исходный код, конфигурацию и локфайл. Существующие переопределения сборки/запуска сервиса обходят используемое здесь определение; см. [порядок решения о сборке](/concepts/build-pipeline#build-decision-order). + + + +## Среда выполнения-конфигурация + +Объявите настройки времени выполнения в `runtimeConfig` и настройте соответствующие значения `NUXT_*` для сервиса. Храните секреты вне `runtimeConfig.public`; публичная часть попадает в браузер. Значения, используемые для предрендеринга страниц, всё равно влияют на сгенерированную сборку, поэтому проверяйте как маршруты времени запроса, так и предрендеренные маршруты после изменений. + +Используйте [переменные и секреты](/variables) для настройки сервиса и [хранилище и восстановление](/platform/storage-and-recovery) для долговечных данных. Не рассматривайте локальный кэш или файл сессии как общее хранилище между репликами. + + + +## Устранение неполадок + +Если процесс сообщает об отсутствующем `.output/server/index.mjs`, проверьте пресет и вывод сборки. Если сообщается об отсутствующем скрипте запуска, добавьте приведённый выше. Если сайт никогда не становится здоровым, проверьте хост и порт. + +Для чисто сгенерированного Nuxt-сайта обслуживайте `.output/public/` с помощью статического Dockerfile и правильной обработкой маршрутов. Не запускайте этот вывод командой Node из примера выше. [Руководство по развертыванию Nuxt](https://nuxt.com/docs/4.x/getting-started/deployment) объясняет выводы Node и генерации; [статические маршруты и 404](/framework-guides/static-routing) описывает настройку статического сервера Lizard. + + + +## Генерация статического сайта + +Для HTML-генерации замените Node-пресет на явные настройки prerender и измените скрипт сборки на `nuxt generate`: + +```ts +export default defineNuxtConfig({ + nitro: { + prerender: { crawlLinks: true, routes: ['/'] }, + }, +}); +``` + +Добавьте нелинкованные или динамические маршруты в `routes`, когда краулер не может их обнаружить. Запустите `npm run build` и убедитесь, что существуют `.output/public/index.html` и файлы ваших внутренних маршрутов. В тесте с Nuxt 4.5.2 сохранение `preset: 'node-server'` при переключении только на `nuxt generate` дало fallback-страницы без маршрутов сайта. Успешная сборка сама по себе не гарантировала, что экспорт содержит сайт. + +Используйте Dockerfile и конфигурацию nginx из [статических маршрутов и 404](/framework-guides/static-routing) со скриптом сборки `build`, выходной директорией `.output/public` и портом сервиса `80`. Статический контейнер не запускает серверные маршруты Nuxt и не читает runtime config для уже сгенерированных страниц. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 г. и их ограничений. diff --git a/_locales/ru/framework-guides/react.mdx b/_locales/ru/framework-guides/react.mdx new file mode 100644 index 0000000..21ca1c1 --- /dev/null +++ b/_locales/ru/framework-guides/react.mdx @@ -0,0 +1,83 @@ +--- +description: "Разверните React-приложение, созданное с Vite, на Lizard. Соберите dist, раздайте его на порту 80, настройте клиентскую маршрутизацию и публичные API-переменные, а затем проверьте развернутое приложение." +--- + + + +# Развертывание React с Vite на Lizard + +Lizard собирает React-приложение, использующее Vite, и раздаёт его каталог `dist/` через nginx на порту `80`. Это руководство охватывает браузерное рендеринг-приложение. Для React-страниц, требующих сервер, следуйте [руководству по Next.js](/framework-guides/nextjs) или предоставьте продакшн-сервер для выбранного React-фреймворка. + + + +## Подготовка сборки + +Используйте существующий проект React и Vite с зафиксированным lockfile. В его `package.json` нужен скрипт продакшн-сборки: + +```json +{ + "scripts": { + "dev": "vite", + "build": "vite build", + "preview": "vite preview" + } +} +``` + +Если ваш шаблон запускает проверки TypeScript перед `vite build`, сохраните эти проверки. Оставьте директорию вывода `dist` по умолчанию у Vite. Пользовательская `build.outDir` требует соответствующий Dockerfile, так как стандартный путь обнаружения копирует `dist`. + +| Параметр | Значение | +|---|---| +| Обнаружение | `vite` в dependencies или dev dependencies | +| Сборка | `npm run build` | +| Вывод | `dist/` | +| Продакшн-сервер | nginx; скрипт запуска Node не нужен | +| Порт сервиса | `80` | + + + +## Локальное тестирование + +```bash +npm ci +npm run build +npm run preview +``` + +Откройте локальный URL превью и протестируйте страницу, обращающуюся к вашему API. Команда превью проверяет сборку локально; не устанавливайте `vite preview` в качестве продакшн-команды запуска. См. [развертывание Vite](https://vite.dev/guide/static-deploy.html). + + + +## Развертывание исходного кода + +После [настройки CLI](/framework-guides#prepare-the-project) выполните из директории, содержащей `package.json`: + +```bash +lizard init --name react-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Загрузите исходный код и lockfile, исключая `node_modules/`, `dist/` и секреты. Оставьте переопределения сборки/запуска сервиса неустановленными, чтобы использовать путь статического обнаружения. Контейнер nginx слушает порт 80, хотя серверы разработки и превью используют другие порты. + + + +## Подключение API + +Используйте публичную переменную, например `VITE_API_URL`, для HTTPS-адреса API, доступного из браузера. Читайте её как `import.meta.env.VITE_API_URL`. Настройте это значение через [переменные и секреты](/variables) и пересобирайте при изменении. Никогда не раскрывайте URL базы данных, учётные данные API или адрес внутреннего сервиса через переменную `VITE_*`. + +Для API на другом источнике настройте его разрешенные источники (allowed origins), чтобы включить URL фронтенда. Приватное имя хоста сервиса, работающее между бэкенд-сервисами, не разрешится в браузере посетителя. + + + +## Проверка маршрутизации + +Откройте живое приложение, перейдите по клиентскому маршруту, затем перезагрузите этот URL напрямую. Стандартный статический сервер делает фоллбэк на `index.html`, чтобы клиентский роутер мог отрендерить внутренний маршрут. Добавьте маршрут для неизвестных путей и в самом React-приложении. Этот фоллбэк всё равно возвращает HTTP 200; используйте [статические маршруты и 404](/framework-guides/static-routing), чтобы выбрать серверную политику для страниц, которым нужны настоящие ответы HTTP 404. + +Если ассет возвращает HTML или страница остаётся пустой, проверьте `base` Vite, запрошенный URL ассета и директорию вывода. Если приложение никогда не становится здоровым (healthy), убедитесь, что порт сервиса — `80`, и что старое переопределение команды запуска не выбрало другой путь сборки. + +Для страниц, предназначенных для поиска, проверьте исходный HTML-ответ. Браузерная оболочка может не содержать текст, который вы ожидаете увидеть у поисковика или answer-движка. Выбирайте prerendering или серверный фреймворк, когда этот текст нужен в ответе. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/framework-guides/static-routing.mdx b/_locales/ru/framework-guides/static-routing.mdx new file mode 100644 index 0000000..1ed7f9a --- /dev/null +++ b/_locales/ru/framework-guides/static-routing.mdx @@ -0,0 +1,107 @@ +--- +description: "Настройте статические маршруты на Lizard: раздавайте сгенерированный HTML, поддерживайте чистые URL, возвращайте HTTP 404 для отсутствующих страниц и выбирайте, когда нужен fallback для SPA." +--- + + + +# Статические маршруты и 404 + +Сайт со статически сгенерированным контентом должен отдавать HTML для каждого маршрута и возвращать HTTP 404 для несуществующей страницы. Новые сборки lizardpack для Astro static, Docusaurus, VitePress, Hugo и SvelteKit adapter-static используют эту политику. React и Vue SPA сохраняют fallback `index.html`, необходимый браузерным роутерам. + +Приведённая ниже пользовательская конфигурация опциональна. Используйте её для политики маршрутизации, которую не предоставляет обнаруженный фреймворк. Существующие образы сохраняют старые правила до следующей пересборки. + + + +## Выбор политики маршрутизации + +| Тип приложения | Поведение маршрутов | +|---|---| +| React или Vue SPA | Валидный клиентский маршрут загружает `index.html`, затем клиентский роутер отрисовывает его. | +| Сгенерированная документация или контент | Маршрут резолвится в свой сгенерированный HTML; неизвестный путь возвращает HTTP 404. | +| Серверно рендеримое приложение | Сервер приложения резолвит маршруты и возвращает статус. | + +Catch-all в SPA может показывать сообщение об отсутствующей странице, но браузерный код не может изменить HTTP-статус уже отправленного HTML-ответа. Если вам нужен route-aware HTTP-статус для SPA, используйте серверную или prerender-настройку, которая знает, какие пути существуют. + + + +## Настройка nginx для сгенерированных страниц + +Создайте `nginx.conf` в корне приложения: + +```nginx +server { + listen 80; + server_name _; + root /usr/share/nginx/html; + index index.html; + + location / { + try_files $uri $uri.html $uri/ =404; + } + + error_page 404 /404.html; + location = /404.html { + internal; + } +} +``` + +Это поддерживает оба варианта структуры вывода `guide.html` и `guide/index.html`. Добавьте сгенерированный `404.html`, если нужна собственная страница ошибки. Иначе опустите блоки `error_page` и exact-location, чтобы использовать стандартное тело ошибки nginx. Используйте один канонический стиль URL в ссылках и sitemap сайта; это правило поиска не добавляет канонические редиректы. + + + +## Сборка сайта с конфигурацией + +Используйте этот полный Dockerfile для npm-проекта с закоммиченным lockfile. Измените `BUILD_SCRIPT` и `OUTPUT_DIR` на значения из таблицы ниже: + +```dockerfile +FROM node:22-slim AS build +WORKDIR /app +COPY package.json package-lock.json ./ +RUN npm ci +COPY . . +ARG BUILD_SCRIPT=build +RUN npm run "$BUILD_SCRIPT" + +FROM nginx:alpine +ARG OUTPUT_DIR=dist +COPY --from=build /app/${OUTPUT_DIR}/ /usr/share/nginx/html/ +COPY nginx.conf /etc/nginx/conf.d/default.conf +EXPOSE 80 +``` + +| Сайт | `BUILD_SCRIPT` | `OUTPUT_DIR` | +|---|---|---| +| Astro static | `build` | `dist` | +| Docusaurus | `build` | `build` | +| VitePress с корнем `docs/` | `docs:build` | `docs/.vitepress/dist` | +| VitePress в корне проекта | `docs:build` или ваш скрипт | `.vitepress/dist` | +| SvelteKit с adapter-static | `build` | `build` | +| Next.js export | `build` | `out` | +| Nuxt generate | `build` с `nuxt generate` | `.output/public` | + +Политику generated-pages используйте только когда у приложения есть эти файлы маршрутов. Например, SPA fallback в SvelteKit требует свою политику маршрутизации. У [Статический экспорт Next.js](/framework-guides/nextjs/static-export) есть полный рецепт с trailing-slash структурой. + +Исключите зависимости, сборку, `.git` и `.env*` в `.dockerignore`. Если сборке нужны публичные переменные, объявите их `ARG` перед командой сборки. Не копируйте приватные секреты в образ или браузерный вывод. + +После [настройки CLI](/framework-guides#prepare-the-project) создайте сервис командой `lizard add --service web`, затем разверните исходники командой `lizard up --service web --port 80`. Шаг add можно пропустить, если сервис уже существует. На существующем сервисе проверьте [порядок принятия решения о сборке](/concepts/build-pipeline#build-decision-order): переопределения командой могут иметь приоритет над Dockerfile. Сам по себе конфиг не заменяет сгенерированную nginx-конфигурацию; Dockerfile должен скопировать его в образ. + + + +## Проверка HTTP-ответов + +Установите `SITE_URL` в реальный локальный тестовый URL или deployed origin, затем замените `/guide/` на существующую страницу: + +```bash +SITE_URL=https://YOUR_PUBLIC_HOST +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/guide/" +curl -sS -o /dev/null -w '%{http_code}\n' "$SITE_URL/this-page-does-not-exist" +``` + +Ожидайте 200 для реальных страниц и 404 для отсутствующего пути. Если валидный маршрут редиректит на каноническую форму, проверьте редирект, а затем верифицируйте цель. Также протестируйте реальный ассет и вымышленный путь `.js`: отсутствующий скрипт не должен возвращать домашнюю страницу как HTML со статусом 200. + +Наконец, откройте внутренний маршрут прямо в браузере и перезагрузите его. Корректная клиентская навигация может скрыть ошибку серверной маршрутизации. Проверьте настройки канонических URL и sitemap фреймворка вместе с HTTP-статусом перед публикацией индексируемого сайта. + +См. [проверенные версии и облачные результаты](/framework-guides/validation) для проверок деплоя 9 сентября 2026 года и их ограничений. + diff --git a/_locales/ru/framework-guides/sveltekit.mdx b/_locales/ru/framework-guides/sveltekit.mdx new file mode 100644 index 0000000..baaf446 --- /dev/null +++ b/_locales/ru/framework-guides/sveltekit.mdx @@ -0,0 +1,110 @@ +--- +description: "Разверните SvelteKit на Lizard с adapter-node. Настройте продакшн-сборку, порт 3000, ORIGIN, серверные экшены и отдельный путь для adapter-static." +--- + + + +# Развертывание SvelteKit на Lizard + +Используйте `@sveltejs/adapter-node` для сборки сервера SvelteKit на Lizard. Он создаёт `build/`, который запускается командой `node build` на порту `3000`. Установите и настройте адаптер явно; каркас, в котором остался `adapter-auto`, не задаёт цель развертывания на Node. + +Начните с [полного примера исходного кода](https://github.com/lizard-build/docs/tree/main/_examples/sveltekit), в котором есть конфигурация и файлы, используемые в этом рецепте. + + + +## Настройка адаптера + +```bash +npm install --save-dev @sveltejs/adapter-node +``` + +В `svelte.config.js` сохраните существующие preprocess и остальные настройки, но задайте `kit.adapter` как Node-адаптер: + +```js +import adapter from '@sveltejs/adapter-node'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +Оставьте только тот адаптер развертывания, который планируете использовать. В частности, неиспользуемая зависимость `@sveltejs/adapter-static` может заставить текущий детектор выбрать статический путь, даже если в конфиге импортирован adapter-node. + +| Параметр | Значение | +|---|---| +| Сборка | `npm run build`, обычно `vite build` | +| Вывод | `build/` | +| Среда выполнения | `node build` | +| Хост и порт | `HOST=0.0.0.0`, `PORT=3000` | +| Порт сервиса | `3000` | + + + +## Проверка продакшн-сервера + +```bash +npm ci +npm run build +HOST=0.0.0.0 PORT=3000 ORIGIN=http://localhost:3000 node build +``` + +Откройте страницу с серверным рендерингом и отправьте форму (form action), если она есть в приложении. Сохраните путь вывода адаптера по умолчанию для детекции, используемой в этом руководстве. + + + +## Развертывание и настройка публичного origin + +После [настройки CLI](/framework-guides#prepare-the-project): + +```bash +lizard init --name sveltekit-app +lizard add --service web +lizard up --service web --port 3000 +lizard ps --json +``` + +Задайте `ORIGIN` равным точному публичному HTTPS-ориджину из вывода развертывания, без пути. Например, замените этот плейсхолдер на свой реальный URL: + +```bash +lizard secrets set ORIGIN=https://YOUR_PUBLIC_HOST --service web +``` + +Используйте кастомный домен вместо этого, если именно он будет ориджином для посетителей. Повторно проверьте формы после изменения переменной. Для нескольких разрешённых ориджинов или URL, полученных через прокси, прочитайте [руководство по Node-серверу SvelteKit](https://svelte.dev/docs/kit/adapter-node) и настройте доверенные заголовки прокси намеренно. + + + +## Верификация и устранение неисправностей + +Изучайте логи сборки и рантайма с помощью `lizard logs --build --service web --json` и `lizard logs --service web --json`. Откройте внутренний маршрут напрямую, отправьте форму и запросите несуществующий маршрут. + +Если формы выдают ошибку межсайтовой отправки, проверьте `ORIGIN` до отключения проверки безопасности. Если `node build` не находит сервер, убедитесь в активном адаптере и пути вывода. Оставьте переопределения команды сервиса не заданными, чтобы использовался путь lizardpack. + + + +## Статические сайты SvelteKit + +Приложение, которое может предрендерить все нужные страницы, может использовать `@sveltejs/adapter-static`, его вывод `build/` по умолчанию и порт сервиса `80`. Такой вывод не может запускать серверные экшены или эндпойнты во время запроса. Настройте предрендеринг для нужных маршрутов; установка пакета одной недостаточна. + +Установите `@sveltejs/adapter-static` и замените импорт адаптера в `svelte.config.js`: + +```js +import adapter from '@sveltejs/adapter-static'; + +export default { + kit: { adapter: adapter() }, +}; +``` + +Для сайта, все маршруты которого можно сгенерировать, добавьте это в `src/routes/+layout.js`: + +```js +export const prerender = true; +export const trailingSlash = 'always'; +``` + +Удалите неиспользуемые адаптеры развертывания из зависимостей. Запустите `npm run build` и проверьте, что `build/` содержит каждую требуемую страницу. Для вывода по умолчанию оставьте переопределения команды сервиса не заданными и разверните новый сервис на порту `80`. Новые сборки будут отдавать сгенерированный HTML и возвращать HTTP 404 для отсутствующих страниц. Не используйте повторно порт `3000` из серверного рецепта для nginx. + +Используйте [статические маршруты и 404](/framework-guides/static-routing), чтобы выбирать между сгенерированными HTML-маршрутами и SPA-фолбэком. См. [SvelteKit static adapter](https://svelte.dev/docs/kit/adapter-static) для опций и ограничений фреймворка. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 года и их ограничений. + diff --git a/_locales/ru/framework-guides/validation.mdx b/_locales/ru/framework-guides/validation.mdx new file mode 100644 index 0000000..499bf79 --- /dev/null +++ b/_locales/ru/framework-guides/validation.mdx @@ -0,0 +1,72 @@ +--- +description: "Результаты тестов фреймворков от 16 реальных развёртываний Lizard CLI 9 сентября 2026 г.: проверенные версии, маршруты, формы, миграции, канонические URL и ограничения." +--- + + + +# Результаты тестов руководств по фреймворкам + +9 сентября 2026 г. все 16 рецептов для 11 фреймворков успешно прошли локальную сборку и новое облачное развёртывание с Lizard CLI 0.3.95. Мы следовали опубликованной настройке, создавали новый проект и сервис для каждого рецепта и загружали исходный код с помощью `lizard up`. Эти результаты охватывают приведённые ниже версии и небольшие тестовые приложения. + +Облачный запуск прошёл 100 проверок маршрутов, API и форм, а также 45 проверок связанных JavaScript- и CSS-файлов. Миграции Django, запись и чтение из базы данных, а также итоговые URL сайтов Docusaurus и Hugo также прошли успешно. + + + +## Проверенные рецепты + +| Рецепт | Проверенные версии | Порт | Облачная проверка | +|---|---|---|---| +| Next.js server | Next.js 16.3.4, React 19.2.8 | `3000` | Успешно | +| Статический экспорт Next.js | Next.js 16.3.4, React 19.2.8 | `80` | Успешно | +| React with Vite | React 19.2.8, Vite 8.2.2 | `80` | Успешно | +| Vue with Vite | Vue 3.5.42, Vue Router 5.3.1, Vite 8.2.2 | `80` | Успешно | +| Astro static | Astro 7.3.1 | `80` | Успешно | +| Astro Node сервер | Astro 7.3.1, Node adapter 11.1.5 | `3000` | Успешно | +| Nuxt Node server | Nuxt 4.5.2 | `3000` | Успешно | +| Nuxt generate | Nuxt 4.5.2 | `80` | Успешно | +| SvelteKit Node-сервер | SvelteKit 2.70.3, Svelte 5.57.0, adapter-node 5.5.7 | `3000` | Успешно | +| SvelteKit static | SvelteKit 2.70.3, Svelte 5.57.0, adapter-static 3.0.10 | `80` | Успешно | +| Docusaurus | Docusaurus 3.10.2 | `80` | Успешно | +| VitePress, корень документации | VitePress 1.6.4 | `80` | Успешно | +| VitePress, корень проекта | VitePress 1.6.4 | `80` | Успешно | +| FastAPI | FastAPI 0.141.1, Uvicorn 0.52.4 | `8000` | Успешно | +| Django | Django 6.1.1, Gunicorn 26.2.0, WhiteNoise 6.12.0, psycopg 3.3.5 | `8000` | Успешно | +| Hugo | Hugo 0.165.0 (extended) | `80` | Успешно | + +JavaScript-сборки использовали Node 22; Python-сборки — Python 3.13. Загрузки выполнялись с macOS без `COPYFILE_DISABLE`. Манифесты пакетов и lock-файлы фиксируют приведённые выше версии. Теги контейнерных образов могут меняться независимо от lock-файла пакетов. + + + +## Что мы проверяли 9 сентября + +- Выполняли задокументированные команды локальной сборки и запуска сервера в Linux-контейнерах, затем запускали `lizard init`, `lizard add` и `lizard up` для каждого рецепта. Читали облачные логи сборки и рантайма и проверяли итоговое состояние сервиса и порт. +- Запрашивали публичную главную страницу, внутренний маршрут, реальный ассет, отсутствующую страницу и отсутствующий JavaScript-путь. Статические сайты возвращали настоящие 404 ошибки; React и Vue сохраняли свой задокументированный SPA-фоллбэк. Обе компоновки VitePress возвращали правильный контент по чистым URL. +- Проверяли ответы API во время запроса, POST-обработчики, результаты форм SvelteKit и отклонение формы с ненадёжного источника. Отправляли развёрнутую форму Next.js Server Действие через HTTP, используя её сгенерированный ID действия, и проверяли редирект и возвращаемое значение. +- Пересобирали Docusaurus и Hugo после установки сгенерированного хоста в конфиге. Канонические URL Docusaurus и обе карты сайта использовали публичный хост. +- Запускали миграции Django против Managed Postgres дважды, записывали и читали тестовую строку, отдавали собранные статические файлы, принимали валидную CSRF-форму и отклоняли форму без токена. + +Каждый рецепт использовал отдельный тестовый проект с разными именами для изоляции запуска. Рабочая область, регион и JSON-флаги делали контекст теста явным. Переопределения сервиса для сборки, запуска и пути к Dockerfile оставались неустановленными. Только рецепты Статический экспорт Next.js, Nuxt generate и Django предоставляли Dockerfile, задокументированные в своих руководствах. Тесты Docusaurus, VitePress, Hugo и SvelteKit Node включали [опубликованные примеры исходного кода](https://github.com/lizard-build/docs/tree/main/_examples). + + + +## Проверки в браузере + +Запуск 9 сентября подтвердил клик по кнопке React в браузере. После этого соединение с браузером возвращало повторяющиеся таймауты при навигации и чтении страниц, поэтому этот запуск **не** утверждает, что все 16 рецептов прошли свежую проверку в браузере. Проверки HTTP-маршрутов и форм прошли независимо. + +Запуск 7 сентября включал перезагрузку прямых маршрутов, взаимодействие с React, навигацию Vue Router, Next.js Server Actions и отправку форм SvelteKit в браузере. Это остаются результатами того более раннего запуска. + + + +## Исправления с первого запуска + +Запуск 7 сентября выявил отсутствующие шаги создания сервиса, несоответствие статического пресета Nuxt, дефекты статической маршрутизации, метаданные архивов macOS, коды выхода при неудачной сборке и ошибки смены порта. Руководства теперь включают `lizard add` и исправленную настройку статического Nuxt. + +Повторная проверка статической маршрутизации 8 сентября прошла без пользовательских Dockerfile для Astro static, SvelteKit static, Docusaurus, Hugo и обеих компоновок VitePress. Новые сборки включают эти правила маршрутизации; существующие образы требуют пересборки. + +Lizard CLI 0.3.95 включает исправления архива и кодов выхода при неудачной сборке. Производственные проверки 9 сентября также верифицировали смену порта сервиса и сохранение явного порта при загрузке и пересборке. См. [известные проблемы](/platform/known-issues) для примечаний к выпуску и оставшихся ограничений. + + + +## Ограничения этих результатов + +Эти проверки охватывают загрузки исходного кода и задокументированные режимы. Они не устанавливают поддержку каждого плагина, адаптера, темы, версии фреймворка, пути развёртывания через GitHub, процедуры восстановления базы данных или рабочих нагрузок с несколькими репликами. Небольшое тестовое приложение Django всё ещё выдаёт предупреждения безопасности от `check --deploy`; это не полная производственная настройка безопасности. Эти тесты не измеряют поисковый рейтинг или цитирования ИИ. Проверьте собственные маршруты и операции с данными вашего приложения перед выпуском. diff --git a/_locales/ru/framework-guides/vitepress.mdx b/_locales/ru/framework-guides/vitepress.mdx new file mode 100644 index 0000000..a2e5b6f --- /dev/null +++ b/_locales/ru/framework-guides/vitepress.mdx @@ -0,0 +1,78 @@ +--- +description: "Развертывание VitePress на Lizard с docs:build, правильной директорией .vitepress/dist, nginx и портом 80. Настройка чистых URL и проверка маршрутов документации и 404." +--- + + + +# Развертывание VitePress на Lizard + +Lizard может собрать сайт документации VitePress и отдать сгенерированный HTML через nginx на порту `80`. Соотнесите npm-скрипт и выходную директорию с корнем вашей документации: `vitepress build docs` пишет в `docs/.vitepress/dist`, а `vitepress build` пишет в `.vitepress/dist`. + +Начните с [полного примера исходного кода](https://github.com/lizard-build/docs/tree/main/_examples/vitepress), который включает конфигурацию и файлы, используемые в этом рецепте. + + + +## Установите скрипт сборки + +Для Markdown-файлов в `docs/` оставьте эти скрипты в `package.json`: + +```json +{ + "scripts": { + "docs:dev": "vitepress dev docs", + "docs:build": "vitepress build docs", + "docs:preview": "vitepress preview docs" + } +} +``` + +| Настройка | Значение в этом руководстве | +|---|---| +| Сборка | `npm run docs:build` | +| Корень документации | `docs/` | +| Выход | `docs/.vitepress/dist/` | +| Продакшн-сервер | nginx | +| Порт сервиса | `80` | + +Детектор находит скрипт, содержащий `vitepress build`, и использует его аргумент root. Держите этот скрипт прямым и однозначным. Обёртки оболочки, несколько подходящих скриптов или пользовательский `outDir` требуют явной конфигурации сборки или Dockerfile. + + + +## Проверьте сайт локально + +```bash +npm ci +npm run docs:build +npm run docs:preview +``` + +Проверьте внутреннюю страницу Markdown и ассет. С `cleanUrls: true` VitePress ссылается на маршруты без расширения; продакшн-сервер должен разрешать эти URL к сгенерированным HTML-файлам. Установите `base` на фактический префикс пути или `/` для корня домена. См. [развертывание VitePress](https://vitepress.dev/guide/deploy). + + + +## Разверните + +После [настройки CLI](/framework-guides#prepare-the-project) выполните из директории, содержащей `package.json`, а не изнутри `docs/`: + +```bash +lizard init --name vitepress-docs +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Включите конфигурацию VitePress, Markdown, исходные ассеты, манифест пакета и lockfile. Исключите локальные зависимости, сгенерированный вывод, кэши и секреты. Не устанавливайте `vitepress dev` или `vitepress preview` как команду запуска сервиса. + + + +## Проверьте чистые маршруты и HTTP-статус + +Новые сборки VitePress разрешают маршруты без расширения к их сгенерированным файлам `.html` и возвращают HTTP 404 для несуществующих URL. Оставьте переопределения команд не заданными, чтобы использовать этот путь обнаружения. Пользовательский Dockerfile не нужен для стандартного вывода. См. [статические маршруты и 404](/framework-guides/static-routing) для пользовательской маршрутизации. + +Проверьте чистый URL напрямую и перезагрузите его. Запросите несуществующий путь и подтвердите HTTP 404. Если старый образ отдаёт главную страницу для отсутствующих путей, пересоберите сервис, чтобы подхватить актуальные правила маршрутизации. + +Если сборка сообщает `Missing script: build`, проверьте, что выбранный путь использует детектор VitePress, и что никакое переопределение команды сервиса его не заменяет. Если сборка прошла успешно, но nginx не отдаёт документацию, сравните docs root скрипта со скопированной выходной директорией. Пересоберите после изменений контента или конфигурации. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для проверок развертывания от 9 сентября 2026 года и их ограничений. + diff --git a/_locales/ru/framework-guides/vue.mdx b/_locales/ru/framework-guides/vue.mdx new file mode 100644 index 0000000..46b3d6d --- /dev/null +++ b/_locales/ru/framework-guides/vue.mdx @@ -0,0 +1,70 @@ +--- +description: "Развёртывание Vue-приложения, собранного Vite, на Lizard. Настройка выходной папки dist, порта 80, режима history Vue Router, публичных переменных окружения и проверок для продакшена." +--- + + + +# Развёртывание Vue с Vite на Lizard + +Развёрните Vue-приложение, собранное Vite, как статический веб-сервис на Lizard. Сборка выдаёт `dist/`, а nginx отдаёт файлы на порту `80`. Для серверного рендеринга и серверных маршрутов Nuxt используйте [гайд по Nuxt](/framework-guides/nuxt). + + + +## Подготовка проекта + +Выполните из директории Vue-приложения с `package.json`, lock-файлом и конфигурацией Vite. Оставьте скрипт сборки из заготовки, включая `vue-tsc`, если он проверяет ваш TypeScript-код. Сборка должна завершиться созданием Vite-бандла в `dist/`. + +| Параметр | Значение | +|---|---| +| Сборка | `npm run build` | +| Выход | `dist/` | +| Команда запуска | Нет для пути статического обнаружения | +| Порт сервиса | `80` | + +Оставьте `base: '/'` для сайта в корне домена. Если используется префикс пути, синхронизируйте base в Vite с base роутера и URL, по которому реально работает приложение. Пользовательская выходная директория требует Dockerfile, копирующего эту директорию. + + + +## Локальная проверка сборки + +```bash +npm ci +npm run build +npm run preview +``` + +Используйте локальный preview-URL, чтобы проверить компонент, загружающий данные, и страницу, доступную через роутер. `vite preview` предназначен для этой локальной проверки; nginx отдаёт продакшен-файлы. См. [гайд по деплою Vite](https://vite.dev/guide/static-deploy.html) для описания результатов сборки и поведения preview. + + + +## Деплой + +После [настройки CLI](/framework-guides#prepare-the-project) развёрните текущую исходную директорию: + +```bash +lizard init --name vue-app +lizard add --service web +lizard up --service web --port 80 +lizard logs --build --service web --json +lizard ps --json +``` + +Исключите из загрузки локальные зависимости, `dist/` и файлы `.env`. Если нет переопределений команд, lizardpack распознаёт Vite и соберёт статический образ. Не добавляйте `npm run dev` как команду запуска сервиса. + + + +## Режим history Vue Router + +Если приложение использует `createWebHistory`, сервер должен обрабатывать прямые запросы к клиентским маршрутам. Стандартный статический образ отдаёт `index.html`, когда не находит файл, поэтому `/account` может дойти до Vue Router при жёсткой перезагрузке. Подогнать base роутера под base Vite можно, например, через `createWebHistory(import.meta.env.BASE_URL)`. См. [режимы history в Vue Router](https://router.vuejs.org/guide/essentials/history-mode.html). + +Проверьте и навигацию с главной страницы, и открытие `/account` в новой вкладке. Добавьте общий вариант представления для отсутствующих клиентских маршрутов. Фолбэк сервера возвращает HTTP 200 даже для неизвестных путей; он не выдаёт SEO-ориентированные ответы 404. Прочитайте [статические маршруты и 404](/framework-guides/static-routing) перед использованием этой конфигурации для индексируемого контентного сайта. + + + +## Переменные и запросы к API + +Vite встраивает значения `VITE_*` в браузерный бандл во время сборки. Используйте их только для публичных значений, например публичного HTTPS-URL вашего API. Задайте их через [переменные и секреты](/variables), затем проверьте реальный сетевой запрос пересобранного приложения. Перезапуск только во время выполнения не может заменить значение внутри собранного JavaScript. + +Если запросы падают только после деплоя, проверьте CORS на API и убедитесь, что браузер не обращается к `localhost` или к приватному хосту бэкенда. Если HTML загрузился, но ассеты нет — проверьте base в Vite и пути к ассетам. Для страниц, которым нужен HTML до запуска JavaScript, выбирайте рендеринг Nuxt или явный шаг пререндеринга. + +См. [проверенные версии и результаты в облаке](/framework-guides/validation) для итогов проверок деплоя 9 сентября 2026 года и их ограничений. diff --git a/_locales/ru/getting-started.mdx b/_locales/ru/getting-started.mdx new file mode 100644 index 0000000..330c27f --- /dev/null +++ b/_locales/ru/getting-started.mdx @@ -0,0 +1,134 @@ +--- +description: "Установите Lizard CLI, войдите в систему и отправьте свое первое приложение из репозитория GitHub или локальной папки за несколько минут, а затем добавьте базу данных." +--- + + + +# Быстрый старт приложения + +Отправьте свое первое приложение на Lizard за несколько минут. Вам понадобятся Node.js 18+ и npm — аккаунт Lizard создается автоматически при первом запуске `lizard login`. Вы установите CLI, войдете в систему и выполните развертывание — прямо из репозитория GitHub или из локальной директории. + + + +## 1. Установите CLI + +Установите бинарный файл `lizard` глобально из npm: + +```bash +npm install -g @lizard-build/cli +``` + +Проверьте, что он доступен в `PATH`: + +```bash +lizard --version +``` + +> **Не используйте `npx`.** Всегда используйте глобально установленный бинарный файл `lizard`. Запуск `npx @lizard-build/cli` загружает временную копию, версия которой может отличаться от платформы. Обновите на месте позже с помощью `lizard upgrade`. + +> **Ошибки прав доступа (EACCES)?** Не используйте `sudo`. Укажите npm пользовательский префикс: +> ```bash +> mkdir -p ~/.npm-global +> npm config set prefix ~/.npm-global +> echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc && source ~/.zshrc +> npm install -g @lizard-build/cli +> ``` + + + +## 2. Войдите в систему + +```bash +lizard login +``` + +Откроется браузер для аутентификации, затем вы вернетесь в терминал после подтверждения. В CI или других неинтерактивных средах аутентифицируйтесь с токеном: + +```bash +export LIZARD_TOKEN=lzd_xxx +# or +lizard login --token lzd_xxx +``` + +Проверьте, под кем вы вошли, в любой момент: + +```bash +lizard whoami +``` + + + +## 3. Разверните + +Выберите способ в зависимости от того, где находится ваш код. + + + +### Вариант А — Развертывание репозитория GitHub (рекомендуется) + +Если ваш код на GitHub, создайте сервис прямо из репозитория. Lizard клонирует его, автоматически определит стек, соберет и вернет рабочий URL: + +```bash +lizard add -r your-org/your-app +``` + +Пуши в отслеживаемую ветку будут автоматически переразвертывать приложение. Для приватных репозиториев сначала подключите GitHub App: + +```bash +lizard git connect +``` + + + +### Вариант Б — Развертывание локального кода + +Изнутри директории проекта загрузите и разверните текущую папку (с учетом `.gitignore`): + +```bash +lizard up +``` + +Если директория еще не привязана к проекту, `up` создаст или выберет его интерактивно. В CI сначала привяжите явно с помощью `lizard init --name my-project`. + +В любом случае, когда сборка завершится, вы получите сгенерированный URL вроде `https://your-app-production.onlizard.com`. + + + +## 4. Следите за сборкой и работой + +```bash +lizard ps # services in the project, with status + URL +lizard logs # last runtime log lines +lizard logs --build # the most recent build's logs +lizard open # open the project in the dashboard +``` + + + +## 5. Добавьте базу данных (по желанию) + +Создайте управляемый Postgres и подключите его к сервису: + +```bash +lizard add postgres +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service your-app +lizard redeploy --service your-app +``` + +Ссылка `${{postgres.DATABASE_URL}}` разрешается во время развертывания и автоматически ротируется вместе с аддоном. См. [Управляемые аддоны](/addons). + + + +## Дальнейшие шаги + +- **[Основные концепции](/concepts/architecture)** — поймите проекты, сервисы и конвейер сборки. +- **[Развертывание из GitHub](/deploy/github)** — ветки, монорепозитории и автопереразвертывание. +- **[Переменные и секреты](/variables)** — области видимости и приоритет. +- **[Сеть](/networking)** — подключите свой хостнейм с автоматическим TLS. +- **[Развертывание приложения, созданного вашим AI IDE](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production)** — те же три шага, переданные агенту, для приложения на Google Antigravity. + + + +## Стоимость хостинга + +Lizard использует [pay as you go](/platform/billing) без ежемесячной подписки. Использование ресурсов списывается с баланса аккаунта. Купленные средства не истекают; у пробных средств срок действия истекает. Проверьте [цены](https://lizard.build/pricing) и лимиты аккаунта перед развертыванием. diff --git a/_locales/ru/guides/_meta.ts b/_locales/ru/guides/_meta.ts new file mode 100644 index 0000000..b16b960 --- /dev/null +++ b/_locales/ru/guides/_meta.ts @@ -0,0 +1,2 @@ +export default { index: "Выберите руководство", 'deploy-from-coding-agent': "Деплой из кодинг-агента", 'deploy-mcp-server': "Запустите удалённый MCP-сервер", 'telegram-bot': "Запустите Telegram-бота", umami: "Запустите Umami", flowise: "Запустите Flowise с PostgreSQL", validation: "Результаты тестов" }; + diff --git a/_locales/ru/guides/deploy-from-coding-agent.mdx b/_locales/ru/guides/deploy-from-coding-agent.mdx new file mode 100644 index 0000000..f315a42 --- /dev/null +++ b/_locales/ru/guides/deploy-from-coding-agent.mdx @@ -0,0 +1,139 @@ +--- +description: "Разверните приложение из Claude Code, Codex или Cursor с помощью Lizard Skill и Lizard CLI. Выберите GitHub или локальный источник, подключите базу данных и проверьте результат." +--- + + + +# Развёртывание из кодинг-агента + +Кодинг-агент может использовать Lizard Skill и Lizard CLI для развёртывания созданного им приложения. Агент читает руководство установленного CLI, проверяет целевой проект, запускает сборку и анализирует результат. Для этого не требуется отдельный MCP-транспорт. + + + +## Перед началом + +Подготовьте рабочее приложение, разрешение на его развёртывание и аккаунт на Lizard. Приложение должно слушать на `0.0.0.0` и настроенном порту. Запустите локальные проверки приложения перед стартом облачной сборки. + + + +## Передайте агенту актуальное руководство + +```bash +npm install -g @lizard-build/cli +lizard skills get core --json +lizard --help --json +``` + +Lizard Skill загружает инструкции, соответствующие установленному CLI. Для конкретной команды читайте её схему вместо угадывания флагов: + +```bash +lizard up --help --json +lizard service set --help --json +``` + +Полезный промпт: + +> Разверни это приложение с помощью Lizard. Прочитай руководство установленного CLI, проверь связанный проект и сервис, запусти проверки приложения и покажи результат сборки и рабочий URL. Спроси перед изменением существующего продакшн-сервиса или удалением данных. + + + +## Развёртывание локального исходного кода + +Для полноценного теста используйте [пример agent-app](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/agent-app). Он использует Node.js 22 и `pg` 8.16.3, слушает порт 3000 и читает одну строку из Managed Postgres. При запуске создаёт демо-таблицу и строку, если их нет. Для более крупного приложения используйте свой процесс миграций. + +Скопируйте пример в отдельную директорию и запустите локальные проверки: + +```bash +npm ci +npm run check +lizard status --json +``` + +Это проверяет JavaScript-синтаксис. Проверки базы данных и публичного HTTP приходят после развёртывания. Если эта директория уже связана, убедитесь, что это тот проект. Для нового тестового проекта: + +```bash +lizard init --name agent-example --json +lizard add --service api --json +lizard add postgres --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api --json +lizard up --service api --port 3000 --json +``` + +Используйте фактическое имя базы, если оно не `postgres`. Сохраните ссылку в кавычках, чтобы локальная оболочка не расширила её. Настройте перед первым развёртыванием. Входите через `lizard login` только если команда сообщает, что требуется аутентификация. + +Путь загрузки намерен для этого скопированного примера. Для приложения, уже находящегося в GitHub, используйте следующий раздел. В macOS с Lizard CLI 0.3.92 выполните `COPYFILE_DISABLE=1 lizard up --service api --port 3000 --json`, чтобы исключить метаданные AppleDouble. В этой версии CLI неудачная сборка может завершиться с кодом 0: изучите терминальное событие `failed`/`deployed` и проверьте приложение. См. [известные проблемы](/platform/known-issues). + + + +## Развёртывание из GitHub + +Используйте этот путь, когда у приложения есть репозиторий GitHub. Сначала проверьте удалённый репозиторий: + +```bash +git remote get-url origin +lizard status --json +lizard ps --json +``` + +Используйте связанный тестовый проект или создайте его через `lizard init --name YOUR_PROJECT_NAME`. Подключите репозиторий без запуска сборки, чтобы успеть настроить окружение: + +```bash +lizard add --repo YOUR_ORG/YOUR_REPO --name api-git --no-deploy --json +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api-git --json +``` + +Сначала подключите Managed Postgres, если у проекта его нет. Эта последовательность использует тот же пример на Node.js. Для репозитория с приложением в поддиректории или на другой ветке настройте перед развёртыванием: + +```bash +lizard service set api-git --set branch=YOUR_BRANCH --set rootDirectory=YOUR_APP_DIRECTORY --set containerPort=3000 --json +lizard redeploy --service api-git --json +``` + +Для приложения в корне репозитория на `main` опустите команду `service set`. Укажите правильный порт, если ваше приложение использует другой. Если репозиторий недоступен для Lizard, подключите GitHub App; не заменяйте этот путь загрузкой молча. + +Для последующих обновлений существующего GitHub-сервиса используйте `lizard redeploy --service api-git` или отправьте изменения в отслеживаемую ветку, если включён автодеплой. `lizard up` переключает сервис на загрузку исходников. Изменение настроек сборки у уже запущенного сервиса может запустить собственную сборку; изучите события перед запросом следующей. + + + +## Проверка результата + +Читайте логи сборки и рантайма отдельно: + +```bash +lizard logs --build --service api --json +lizard logs --service api --json +lizard ps --json +``` + +Для GitHub-пути используйте `api-git` вместо `api`. Установите `APP_URL` в HTTPS URL, сообщенный CLI, затем выполните: + +```bash +curl --fail "$APP_URL/health" +curl --fail "$APP_URL/data" +``` + +Первый ответ — `App ready`. Второй — `{"value":"database-connected"}`. Одна сборка не доказывает, что ссылка на базу разрешилась. Пример показывает только эту фиксированную демо-строку, а не API администрирования базы. + +Для этого тестового сервиса проверьте перезапуск рантайма: + +```bash +lizard restart --service api --json +``` + +Дождитесь, пока сервис вернётся в `running` в `lizard ps --json`, и повторите оба HTTP-запроса. Хвост рантайм-лога может быть пустым; HTTP-ответ — это проверка приложения. Строка хранится в Managed Postgres; процесс сервиса её не хранит. Для проверки повторного использования существующих данных обновите демо-строку на уникальное значение в редакторе базы перед перезапуском и подтвердите, что `/data` возвращает это значение после. + +`logs --json` возвращает хвост лога и завершается. Прочитайте [хранилище и восстановление](/platform/storage-and-recovery) перед изменением реальных данных приложения. + + + +## Когда развёртывание падает + +Используйте код выхода и JSON-ошибку упавшей команды. Ошибка компиляции, процесс, который завершается, и недоступный порт требуют разных исправлений. См. [JSON и автоматизация](/cli/json) и [сервис никогда не становится healthy](/deploy/troubleshooting/service-never-healthy). `redeploy` — это новая сборка, а не откат к старой версии. + + + +## Лимиты и стоимость + +Агент может создавать оплачиваемые ресурсы через тот же CLI, что и человек. Проверьте [лимиты](/platform/limits) и [цены](https://lizard.build/pricing), и ограничьте права учётных данных нужными проектами и сервисами. + +См. [результаты сценарийных тестов](/guides/validation) для проверенных версий, облачных результатов и оставшихся лимитов. diff --git a/_locales/ru/guides/deploy-mcp-server.mdx b/_locales/ru/guides/deploy-mcp-server.mdx new file mode 100644 index 0000000..22df9e1 --- /dev/null +++ b/_locales/ru/guides/deploy-mcp-server.mdx @@ -0,0 +1,116 @@ +--- +description: "Разместите удалённый MCP-сервер на Lizard с Streamable HTTP, проверкой bearer-токенов, эндпоинтом здоровья и клиентом, который верифицирует вызов инструмента." +--- + + + +# Разместите удалённый MCP-сервер + +Разверните MCP-сервер как HTTP-приложение, когда клиентам нужен удалённый URL. Этот пример обслуживает один арифметический инструмент, валидирует bearer-токен и предоставляет эндпоинт здоровья. Он использует Streamable HTTP; локальный сервер `stdio` сам по себе не может обслуживать удалённых клиентов. + + + +## Прежде чем начать + +Вам понадобятся Node.js 22, Lizard CLI, проект, в который можно сделать деплой, и MCP-клиент, принимающий настроенный bearer-токен. В примере используется `@modelcontextprotocol/sdk` 1.30.0 в режиме без сохранения состояния. Он не предоставляет OAuth-авторизацию, доступ из браузера или провайдера идентификации. + +Исполняемые файлы находятся в [remote-mcp-node](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/remote-mcp-node). Используйте зафиксированный lockfile. Локальный дымовый тест проверяет инициализацию, обнаружение инструментов, вызов инструмента и отклонение без валидного токена. Проверка деплоя также должна подтвердить работу публичного прокси и TLS-пути. + + + +## Запуск локально + +Из директории примера: + +```bash +npm ci +npm test +node issue-token.mjs +export MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" +export MCP_ALLOWED_HOSTS=127.0.0.1,localhost +npm start +``` + +Сгенерированный токен истекает через один час. Приватный ключ подписи не сохраняется. Используйте свой собственный процесс выпуска и ротации токенов для постоянного деплоя; держите его приватный ключ вне сервера. + +В другом терминале: + +```bash +export MCP_URL=http://127.0.0.1:8000/mcp +export MCP_TOKEN="$(cat .mcp-token)" +node client.mjs +``` + +Клиент проверяет инициализацию, обнаружение инструментов и результат `5`, затем печатает `MCP initialize, tools/list and tools/call passed: 5`. `/health` возвращает `ok`; запрос к `/mcp` без валидного токена возвращает `401`. + + + +## Деплой приложения + +Сохраните Dockerfile и lockfile примера. Из директории, содержащей их: + +```bash +lizard init --name mcp-example +lizard add --service mcp +lizard domain --service mcp --json +``` + +Выполните вход через `lizard login`, если команда сообщает, что требуется аутентификация. `init` связывает проект; `add` создаёт именованный сервис. Команда domain назначает его хостнейм перед деплоем. Используйте возвращённый `hostname` ниже, без `https://` или пути: + +```bash +lizard secrets set MCP_PUBLIC_KEY="$(cat .mcp-public-key.pem)" --service mcp +lizard secrets set MCP_ALLOWED_HOSTS=YOUR_SERVICE_HOSTNAME --service mcp +``` + +Задайте оба значения перед первым деплоем. Затем запустите: + +```bash +lizard up --service mcp --port 8000 +lizard logs --build --service mcp --json +lizard logs --service mcp --json +lizard ps --json +``` + +На macOS с Lizard CLI 0.3.92 используйте `COPYFILE_DISABLE=1 lizard up --service mcp --port 8000`, чтобы исключить метаданные AppleDouble из архива. Более поздний релиз CLI может включать исправление архива. Проверяйте финальное событие деплоя и публичный эндпоинт; не полагайтесь только на код выхода этой версии CLI после неудачной сборки. `server.mjs` слушает на `0.0.0.0` и читает `PORT`, с 8000 в качестве значения по умолчанию. Команда деплоя устанавливает порт сервиса в 8000. Настройте публичный ключ как многострочное значение переменной окружения; не загружайте приватный ключ подписи или файл токена. + + + +## Проверьте публичный эндпоинт + +Установите `MCP_URL` в `https://YOUR_SERVICE_HOSTNAME/mcp`, сохраните валидный токен в окружении клиента и запустите `node client.mjs`. Проверьте все три результата: + +1. `/health` возвращает `200` по HTTPS. +2. `/mcp` отклоняет клиента без валидного токена. +3. Аутентифицированный клиент перечисляет инструменты и вызывает `add`, возвращая `5`. + +Здоровый процесс сам по себе не доказывает, что MCP-рукопожатие или стриминговый ответ работают через публичный прокси. + + + +## Устранение неполадок + +| Результат | Проверка | +|---|---| +| Процесс завершается при запуске | `MCP_PUBLIC_KEY` должен содержать публичный PEM-ключ; `MCP_ALLOWED_HOSTS` должен содержать хостнейм сервиса. | +| `401` | Токен должен использовать RS256, соответствовать issuer и audience `mcp-example` и не должен быть истёкшим. | +| `403` | Сопоставьте хостнейм запроса с `MCP_ALLOWED_HOSTS`. Браузерные источники в этом примере не включены. | +| `405` с валидным токеном | Этот stateless MCP-эндпоинт принимает протоколные запросы через POST. Используйте MCP-клиент. Браузерный GET без токена сначала возвращает `401`. | +| Локальный тест проходит, но удалённый вызов не работает | Проверьте порт, HTTPS, стриминг ответа и таймауты прокси. | + + + +## Ограничения и стоимость + +Этот пример не хранит пользовательские сессии или постоянные файлы в памяти сервера. Добавьте базу данных для долговременного состояния приложения и проверяйте доступ по пользователю перед раскрытием приватных инструментов. Для клиентов, требующих OAuth-обнаружение или интерактивный вход, добавьте поддерживаемого OAuth-провайдера вместо распространения этого тестового токена. + +HTTP-процесс может оставаться активным между вызовами. Проверьте [цены](https://lizard.build/pricing), [лимиты](/platform/limits) и измеренные CPU/память; пустая очередь запросов не означает отсутствие расходов. + + + +## Следующие шаги + +- [Ссылки на окружение](/variables/references) +- [Восстановление деплоя](/concepts/deployments) +- [Руководство по MCP TypeScript SDK серверу](https://ts.sdk.modelcontextprotocol.io/server) + +См. [результаты сценарийных тестов](/guides/validation) для проверенных версий, облачных результатов и оставшихся лимитов. diff --git a/_locales/ru/guides/flowise.mdx b/_locales/ru/guides/flowise.mdx new file mode 100644 index 0000000..f8196f2 --- /dev/null +++ b/_locales/ru/guides/flowise.mdx @@ -0,0 +1,165 @@ +--- +description: "Развернуть Flowise with PostgreSQL, preserve its credential encryption key, and check saved flows after restarts and upgrades." +--- + + + +# Запуск Flowise с PostgreSQL + +В этом руководстве разворачивается один сервис Flowise на Lizard, с PostgreSQL для хранения потоков, учетных записей и зашифрованных учетных данных. Он создает точную npm-версию и задает ключ шифрования в качестве секрета сервиса. + +Базовая настройка охватывает потоки, использующие API. Загруженные файлы и локальные векторные хранилища требуют отдельного постоянного хранилища; см. [Файловое хранилище](#file-storage) перед использованием этих функций. + + + +## Предварительные требования + +- Учетная запись Lizard с доступом к хостингу приложений и Managed Postgres. +- Node.js, npm и OpenSSL на вашем компьютере. +- Достаточно памяти для вашей рабочей нагрузки Flowise; тестовый сервис использует 4 ГиБ. + +Установите Lizard CLI и завершите вход через браузер: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + + + +## Создание проекта + +```bash +mkdir flowise-on-lizard +cd flowise-on-lizard +lizard init --name flowise-on-lizard +lizard add postgres --name flowise-db +lizard add --service flowise +``` + +Используйте `--workspace ` с `lizard init`, если нужно выбрать рабочую область. Дождитесь, пока база данных запустится. + + + +## Сборка фиксированной версии Flowise + +Создайте `Dockerfile` со следующим содержимым. Это повторяет Docker-сборку Flowise и фиксирует npm-пакет в версии `3.1.4`: + +```dockerfile +FROM node:24-alpine AS build +RUN apk add --no-cache git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev +ENV PUPPETEER_SKIP_DOWNLOAD=true +RUN npm install -g flowise@3.1.4 --legacy-peer-deps + +FROM node:24-alpine +RUN apk add --no-cache chromium git python3 py3-pip py3-setuptools make g++ build-base cairo-dev pango-dev curl +ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser +COPY --from=build /usr/local/lib/node_modules /usr/local/lib/node_modules +COPY --from=build /usr/local/bin /usr/local/bin +RUN chown -R node:node /usr/local/lib/node_modules /usr/local/bin +USER node +EXPOSE 3000 +ENTRYPOINT ["flowise", "start"] +``` + +`--legacy-peer-deps` позволяет не устанавливать опциональные интеграции, включая старую нативную зависимость SQLite. Эта конфигурация рассчитана на PostgreSQL и потоки на основе API; дополнительные зависимости для узлов, которые их требуют, устанавливайте и тестируйте отдельно. + +Укажите Dockerfile явно: + +```bash +lizard service set flowise --set dockerfilePath=Dockerfile +``` + + + +## Настройка PostgreSQL и шифрования + +Ссылайтесь на переменные базы данных в сервисе Flowise: + +```bash +lizard secrets set \ + DATABASE_TYPE=postgres \ + DATABASE_HOST='${{flowise-db.PGHOST}}' \ + DATABASE_PORT='${{flowise-db.PGPORT}}' \ + DATABASE_USER='${{flowise-db.PGUSER}}' \ + DATABASE_PASSWORD='${{flowise-db.PGPASSWORD}}' \ + DATABASE_NAME='${{flowise-db.PGDATABASE}}' \ + --service flowise +``` + +Сохраняйте одинарные кавычки, чтобы ваша оболочка не раскрывала ссылки. Lizard разрешит их при запуске сервиса. + +Сгенерируйте следующие секреты один раз при настройке: + +```bash +lizard secrets set \ + FLOWISE_SECRETKEY_OVERWRITE="$(openssl rand -hex 32)" \ + JWT_AUTH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + JWT_REFRESH_TOKEN_SECRET="$(openssl rand -hex 32)" \ + EXPRESS_SESSION_SECRET="$(openssl rand -hex 32)" \ + TOKEN_HASH_SECRET="$(openssl rand -hex 32)" \ + SECURE_COOKIES=true \ + --service flowise +``` + +Надежно сохраните эти значения. В частности, сохраните `FLOWISE_SECRETKEY_OVERWRITE`: Flowise нужен тот же ключ, чтобы расшифровать учетные данные, уже сохраненные в PostgreSQL. Не регенерируйте секреты при перезапуске, переразвертывании или обновлении. + + + +## Развертывание и создание учетной записи + +```bash +lizard up --service flowise --port 3000 +``` + +Первая сборка устанавливает Flowise и его зависимости, поэтому может занять несколько минут. Откройте возвращенный при развертывании HTTPS-URL и создайте первую учетную запись владельца перед тем, как делиться ссылкой. Войдите в редактор. + +Укажите публичный URL для ссылок, которые генерирует Flowise, заменив пример на ваш реальный HTTPS-URL: + +```bash +lizard secrets set APP_URL=https://YOUR-SERVICE.onlizard.com --service flowise +``` + +Это изменение перезапустит сервис. Настройте SMTP отдельно, если нужны электронные письма для сброса пароля или приглашения. + + + +## Проверка сохранности данных + +Создайте и сохраните поток. Добавьте тестовые учетные данные, затем перезапустите Flowise: + +```bash +lizard restart --service flowise +``` + +Дождитесь, пока сервис запустится, войдите снова и проверьте, что поток и учетные данные остались. Запустите поток, использующий эти учетные данные, чтобы убедиться, что Flowise все еще может их расшифровать. Повторите проверку после повторного развертывания: + +```bash +lizard redeploy --service flowise +``` + +Сделайте резервные копии и PostgreSQL, и ключа шифрования. Резервная копия базы данных без ключа не сможет восстановить сохраненные учетные данные. + + + +## Файловое хранилище + +PostgreSQL не хранит все файлы, которые пишет Flowise. В этой настройке не подключен постоянный том для файлов, поэтому локальные загрузки, локальные векторные базы и файловые журналы могут исчезнуть при замене контейнера. + +Перед использованием загрузок или рабочих процессов с документами настройте частный S3-бакет, используя [переменные хранилища](https://docs.flowiseai.com/configuration/environment-variables) Flowise. Задайте `STORAGE_TYPE=s3`, `S3_STORAGE_BUCKET_NAME`, `S3_STORAGE_ACCESS_KEY_ID`, `S3_STORAGE_SECRET_ACCESS_KEY` и `S3_STORAGE_REGION`. Для S3-совместимого провайдера также задайте `S3_ENDPOINT_URL` и `S3_FORCE_PATH_STYLE=true`. + +Managed Object Storage Lizard создает бакет `default` с публичным доступом на чтение. Не помещайте туда приватные документы Flowise, не изменив сначала настройку доступа. Настройка PostgreSQL выше не предоставляет и не тестирует файловое хранилище, локальные векторные хранилища или рабочие процессы очередей. + + + +## Устранение неполадок и обновления + +```bash +lizard events --service flowise +lizard logs --build --service flowise +lizard logs --service flowise +``` + +Если первое развертывание завершается тайм-аутом, пока образ всё ещё скачивается, проверьте `lizard events`. После запуска контейнера повторите `lizard up --service flowise --port 3000`. Сервис без предыдущей успешной сборки еще не может использовать `lizard redeploy`. + +Для обновлений сделайте резервную копию базы данных, изучите заметки к выпуску Flowise, измените версию npm в Dockerfile и загрузите его снова с помощью `lizard up`. Проверьте новую версию и выполните проверки сохранности перед тем, как полагаться на обновление. diff --git a/_locales/ru/guides/index.mdx b/_locales/ru/guides/index.mdx new file mode 100644 index 0000000..1077a0d --- /dev/null +++ b/_locales/ru/guides/index.mdx @@ -0,0 +1,25 @@ +--- +description: "Руководства по развёртыванию из агентов кода, хостингу удалённых MCP-серверов, запуску Telegram-воркеров и сохранению файлов в песочнице." +--- + + + +# Руководства + +Выберите тип рабочей нагрузки, которую нужно запустить. Каждое руководство описывает настройку, проверки и ограничения; используйте справочник команд, когда нужен точный синтаксис флага. + +| Задача | Руководство | +|---|---| +| Развернуть приложение, написанное Claude Code, Codex или Cursor | [Развертывание из агента кода](/guides/deploy-from-coding-agent) | +| Дать MCP-клиенту удалённый HTTPS-эндпоинт | [Хостинг удалённого MCP-сервера](/guides/deploy-mcp-server) | +| Поддерживать один долгоживущий процесс long-polling Telegram | [Запуск Telegram-бота](/guides/telegram-bot) | +| Обрабатывать очереди задач без HTTP-листенера | [Фоновые воркеры](/deploy/workers) | +| Запускать код в отдельном Linux-госте | [Быстрый старт с Sandboxes](/sandboxes/quickstart) | +| Собирать аналитику сайта с PostgreSQL | [Запуск Umami](/guides/umami) | +| Хранить потоки Flowise и зашифрованные учётные данные в PostgreSQL | [Запуск Flowise](/guides/flowise) | +| Повторно использовать файлы в другой песочнице | [Persistent Volumes](/sandboxes/volumes) | + +Проверьте [ограничения](/platform/limits), [хранилище и восстановление](/platform/storage-and-recovery) и [известные проблемы](/platform/known-issues) при выборе ресурса. + +Ознакомьтесь с [результатами сценарийных тестов](/guides/validation) для проверенных версий, облачных проверок и оставшихся пробелов. + diff --git a/_locales/ru/guides/telegram-bot.mdx b/_locales/ru/guides/telegram-bot.mdx new file mode 100644 index 0000000..9220266 --- /dev/null +++ b/_locales/ru/guides/telegram-bot.mdx @@ -0,0 +1,101 @@ +--- +description: "Запустите Telegram-бота с long polling как рабочего процесса Lizard. Настройте токен, отключите HTTP-маршрутизацию, оставьте одну реплику и проверьте сообщения и повторные попытки." +--- + + + +# Запуск Telegram-бота + +Бот с long polling — это фоновый рабочий процесс: он запрашивает обновления у Telegram и не требует публичного HTTP-эндпоинта. Запустите его с `containerPort=0` и одной репликой на токен бота. + +**Статус тестов:** семь локальных тестов с имитированными ответами Telegram проходят. Мы не проверяли это руководство с реальным ботом в облаке. Используйте отдельного тестового бота и выполните проверки сообщений и перезапуска ниже перед тем, как полагаться на него. См. [результаты сценарийных тестов](/guides/validation). + + + +## Перед началом + +Создайте бота через BotFather и храните его токен в секрете. Вам понадобятся Python 3.13, Lizard CLI и проект, в который можно выполнить деплой. Бот, использующий long polling, не должен иметь активный вебхук; проверьте текущую конфигурацию перед изменением способа получения обновлений. + +В [примере файлов](https://github.com/lizard-build/docs/tree/23635ba7e162bafce75d3f6206553b3ef2c0c48e/_examples/telegram-worker) входят `worker.py`, Dockerfile и локальные модульные тесты. Тесты не обращаются к Telegram. Обработчик эха хранит смещение в памяти; это не система ровно-однократной обработки. + + + +## Локальная проверка + +Из директории примера: + +```bash +python3 -m unittest -v +``` + +Проверки охватывают текстовые ответы, игнорируемые обновления, пустые опросы и неудачные отправки. Запустите бота локально с `TELEGRAM_BOT_TOKEN`, только если планируете отправлять ответы. Остановите этот локальный процесс перед запуском размещённого рабочего процесса. + + + +## Деплой как рабочий процесс + +```bash +lizard init --name telegram-bot +lizard add --service bot +``` + +Выполните вход через `lizard login`, если команда сообщает, что требуется аутентификация. Установите `TELEGRAM_BOT_TOKEN` в **сервисе бота** перед деплоем. Можно использовать редактор переменных в панели управления или поместить значение в локальный файл `.env` и импортировать его: + +```bash +lizard secrets import --service bot < .env +lizard run --service bot -- python3 check_bot.py +lizard up --service bot --port 0 +``` + +Предварительная проверка валидирует токен через `getMe` и отклоняет бота с активным вебхуком. Она не удаляет и не меняет этот вебхук. Второй процесс опроса всё ещё может конфликтовать: остановите любую локальную копию перед деплоем. + +Пример исключает `.env*` из загрузки. Держите токен вне исходных файлов и скриншотов. На macOS с Lizard CLI 0.3.92 добавьте префикс `COPYFILE_DISABLE=1` к команде загрузки. Читайте итоговое событие деплоя и логи даже если команда завершилась успешно. + +Для существующего сервиса явно установите режим рабочего процесса: + +```bash +lizard service set bot --set containerPort=0 +``` + +После смены режима рабочего процесса на запущенном сервисе примените его с `lizard redeploy --service bot`. Проверьте события деплоя перед запросом следующей сборки. Режим рабочего процесса пропускает проверки HTTP-порта и маршрут балансировщика; не добавляйте фиктивный веб-сервер только для того, чтобы этот процесс выглядел как HTTP-приложение. + + + +## Проверка результата + +```bash +lizard ps --json +lizard logs --service bot --json +lizard events --json +``` + +В логе должно появиться `Telegram worker started`. Отправьте сообщение боту и проверьте, пришёл ли один эхо-ответ. Затем остановите и перезапустите рабочий процесс в утвержденное тестовое окно и подтвердите, что он переподключился. Рабочий процесс, помеченный как запущенный, всё равно требует этой проверки на уровне приложения. + + + +## Типичные сбои + +| Симптом | Проверка | +|---|---| +| Процесс завершается сразу | Установите `TELEGRAM_BOT_TOKEN` на потребляющем сервисе. | +| HTTP-проверка здоровья никогда не проходит | Режим рабочего процесса должен использовать `containerPort=0`. | +| Обновления прекращаются или появляются ошибки конфликта | Только один процесс опроса должен использовать этот токен; проверьте локальный процесс, другую реплику или активный вебхук. | +| Повторные ответы после сбоя | Демоверсия не сохраняет смещения и не дедуплицирует ID обновлений. Добавьте устойчивую идемпотентность перед обработкой необратимых действий. | +| Частые повторные попытки | Проверьте сетевой доступ, валидность токена, лимиты Telegram и ваш обработчик. Не печатайте URL запросов: они содержат токен. | + + + +## Состояние и стоимость + +Для устойчивого состояния бота подключите [Managed Postgres](/addons/postgres). Храните обработанные ID обновлений и делайте обработчики безопасными для повторных вызовов. Long polling может держать рабочий процесс активным между сообщениями; планируйте бюджет от [цен](https://lizard.build/pricing) и наблюдаемого потребления ресурсов, а не только от количества сообщений. + + + +## Связанные руководства + +- [Фоновые рабочие процессы](/deploy/workers) +- [Логи](/observability/logs) +- [Лимиты](/platform/limits) +- [Справочник Telegram getUpdates](https://core.telegram.org/bots/api#getupdates) + +См. [результаты сценарийных тестов](/guides/validation) для проверенных версий, результатов в облаке и оставшихся ограничений. diff --git a/_locales/ru/guides/umami.mdx b/_locales/ru/guides/umami.mdx new file mode 100644 index 0000000..00e0f5e --- /dev/null +++ b/_locales/ru/guides/umami.mdx @@ -0,0 +1,122 @@ +--- +description: "Развертывание Umami с Managed Postgres, настройка секретов шифрования и проверка аналитики после перезапуска и повторного развертывания." +--- + + + +# Запуск Umami + +Это руководство запускает официальный Docker-образ Umami на Lizard с отдельной базой данных PostgreSQL. Используется Lizard CLI для развертывания небольшого локального Dockerfile и предоставления Umami через HTTPS. + + + +## Предварительные требования + +- Аккаунт Lizard с доступом к хостингу приложений и Managed Postgres. +- Node.js и npm на вашем компьютере, а также OpenSSL для генерации секретов. + +Установите Lizard CLI и выполните вход: + +```bash +npm install -g @lizard-build/cli +lizard login +``` + +Завершите вход в браузере перед продолжением. Команды ниже тестировались с Lizard CLI 0.3.95 и Umami 3.3.1. + + + +## Создание проекта и базы данных + +Используйте новый каталог для этого развертывания: + +```bash +mkdir umami-on-lizard +cd umami-on-lizard +lizard init --name umami-on-lizard +lizard add postgres --name umami-db +lizard add --service umami +``` + +Если вы состоите более чем в одном рабочем пространстве, передайте `--workspace ` в `lizard init` для выбора одного. Дождитесь, пока база данных достигнет статуса `running`, прежде чем развертывать Umami. + + + +## Настройка образа и секретов + +Создайте файл с именем `Dockerfile`: + +```dockerfile +FROM ghcr.io/umami-software/umami:3.3.1 +EXPOSE 3000 +``` + +Укажите Lizard использовать этот файл как есть: + +```bash +lizard service set umami --set dockerfilePath=Dockerfile +``` + +Подключите базу данных и сгенерируйте два отдельных секрета: + +```bash +lizard secrets set \ + DATABASE_URL='${{umami-db.DATABASE_URL}}' \ + APP_SECRET="$(openssl rand -hex 32)" \ + TWO_FACTOR_ENCRYPTION_KEY="$(openssl rand -hex 32)" \ + --service umami +``` + +Сохраняйте одинарные кавычки вокруг ссылки на базу данных: Lizard разрешит её при запуске сервиса. Значения принадлежат этому сервису, поэтому другие приложения в проекте их не получат. + +Сохраните оба сгенерированных секрета в вашем менеджере паролей. Установите их один раз при настройке; не перегенерируйте их при перезапуске или обновлении. `TWO_FACTOR_ENCRYPTION_KEY` необходим для двухфакторной аутентификации. + + + +## Развертывание и вход + +Из каталога, содержащего Dockerfile, выполните: + +```bash +lizard up --service umami --port 3000 +``` + +Образ Umami при запуске выполняет настройку базы данных и миграции. Для этого образа отдельная команда миграции не требуется. + +Откройте HTTPS-URL, возвращённый при развертывании. Для новой базы данных Umami 3.3.1 войдите с именем пользователя `admin` и паролем `umami`, затем сразу смените пароль в профиле перед тем, как делиться URL. Добавьте веб-сайт и установите его скрипт отслеживания на контролируемой вами странице. + +Если развертывание не удалось, проверьте его статус и логи: + +```bash +lizard events --service umami +lizard logs --build --service umami +lizard logs --service umami +``` + +Если первый запуск завершился таймаутом, проверьте `lizard events` на готовность контейнера. После запуска контейнера повторите загрузку с помощью `lizard up --service umami --port 3000`. + + + +## Проверка сохранности данных + +Посетите отслеживаемую страницу и убедитесь, что Umami фиксирует просмотр страницы. Перезапустите приложение: + +```bash +lizard restart --service umami +``` + +Дождитесь повторного запуска сервиса. Убедитесь, что новый пароль работает и веб-сайт с просмотром страницы сохраняются. Затем повторите проверку после повторного развертывания: + +```bash +lizard redeploy --service umami +``` + +Umami хранит аккаунты, настройки веб-сайтов и аналитику в PostgreSQL. Приложению не нужен файловый том для этих записей. Сохраняйте базу данных и секреты шифрования при замене или обновлении приложения. Проверка перезапуска не заменяет проверенный план резервного копирования и восстановления базы данных. + + + +## Обновление Umami + +Сделайте резервную копию PostgreSQL и изучите примечания к выпуску перед обновлением. Измените тег образа в локальном Dockerfile, затем снова выполните `lizard up --service umami --port 3000`. Для этой настройки на основе загрузки `lizard redeploy` перестраивает последние загруженные файлы; он не загружает локальные правки. + +См. [руководство Lizard по PostgreSQL](https://lizard.build/docs/addons/postgres/) для доступа к базе данных и [хранение и восстановление](https://lizard.build/docs/platform/storage-and-recovery/) для планирования резервного копирования. diff --git a/_locales/ru/guides/validation.mdx b/_locales/ru/guides/validation.mdx new file mode 100644 index 0000000..0703498 --- /dev/null +++ b/_locales/ru/guides/validation.mdx @@ -0,0 +1,39 @@ +--- +description: "Проверки руководств по MCP, кодингагенту, Redis-воркеру и Telegram-боту: облачные результаты, поведение при перезапуске, протестированные версии и оставшиеся ограничения." +--- + + + +# Результаты тестирования сценариев + +7 сентября 2026 года мы проверили эти руководства в отдельном тестовом проекте с Lizard CLI 0.3.92. Проверки приложения отделены от статуса сборки. Тесты использовали команды из руководств, с отдельным именем проекта и веткой документации для примера на GitHub. + +| Руководство | Результат | Проверки | +|---|---|---| +| [Remote MCP](/guides/deploy-mcp-server) | Пройдено локально и в облаке | Health 200; отсутствующий и недействительный токен 401; аутентифицированный GET 405; отклонённый Origin 403; initialize, tools/list и tools/call; результат `5` через публичный HTTPS | +| [Агент программирования: загрузка](/guides/deploy-from-coding-agent) | Пройдено | `lizard up`, health 200, ответ с поддержкой БД 200, неизвестный маршрут 404; обновлённая строка Postgres осталась после перезапуска сервиса | +| [Агент программирования: GitHub](/guides/deploy-from-coding-agent) | Пройдено | Репозиторий подключён с `--no-deploy`; ветка, корневая директория и окружение настроены до `redeploy`; публичное приложение прочитало ту же существующую строку Postgres | +| [Redis worker](/deploy/workers) | Пройдено | Порт 0; постановка в очередь и результат; результат сохранился после перезапуска; новая задача после перезапуска; незавершённая запись обработки восстановлена при запуске | +| [Telegram bot](/guides/telegram-bot) | Только локальные тесты | Семь мок-тестов охватывают обновления, неудачные отправки, проверки токена и отказ вебхука. Требуются настоящий токен, чат и облачный эхо-тест | + + + +## Версии + +Контейнер MCP работал на Node.js 22.23.2 с MCP TypeScript SDK 1.30.0. Пример coding-agent использует `pg` 8.16.3 и подключается к Managed Postgres под PostgreSQL 18.4. Контейнер воркера работал на Python 3.13.15 с redis-py 6.4.0. Файлы блокировок зависимостей или точные требования находятся в примерах. + + + +## Область + +Проверка MCP охватывает stateless HTTP-транспорт примера и фиксированный bearer-токен. Она не устанавливает совместимость с OAuth, поддержку браузера, длительную потоковую передачу или пропускную способность под нагрузкой. Токен истекает через один час. + +Проверка GitHub использовала ветку документации и директорию `_examples/agent-app`. Она тестировала явный перезапуск деплоя; не тестировались все варианты настройки прав для приватных репозиториев или события вебхуков. + +Проверка восстановления Redis засеяла незавершённую запись обработки перед перезапуском единственного консьюмера. Не тестировались сбой Redis, несколько воркеров или гарантии exactly-once для внешних эффектов. Проверка базы данных устанавливает сохранность при перезапуске приложения, а не резервное копирование или аварийное восстановление. + +Хвосты логов рантайма изначально были пусты для тестовых сервисов. Позже живой поток логов воркера доставил только что обработанную задачу. Используйте проверки HTTP, MCP-клиента и результата задачи как критерии завершения; пустой хвост логов сам по себе не подтверждает ни успех, ни неудачу. + +Пример Telegram не помечен как проверенный в облаке. Его префлайт считывает `getMe` и `getWebhookInfo` без изменения вебхука бота. Используйте отдельного тестового бота перед включением цикла опроса. + +См. [результаты тестов фреймворка](/framework-guides/validation) для отдельной партии из 16 рецептов фреймворка, и [известные проблемы](/platform/known-issues) для ограничений архива CLI и кода выхода при неудачной сборке. diff --git a/_locales/ru/index.mdx b/_locales/ru/index.mdx new file mode 100644 index 0000000..1db5d30 --- /dev/null +++ b/_locales/ru/index.mdx @@ -0,0 +1,57 @@ +--- +description: "Разверните приложение, запустите воркер, подключите Managed Postgres или выполните код в Sandboxes. Выберите задачу, следуйте руководству и проверьте лимиты." +--- + + + +# Документация Lizard + +Lizard собирает и запускает приложения из репозитория GitHub или локальной папки. Используйте Lizard CLI или дашборд, чтобы развернуть веб-сервис, запустить фоновый воркер, подключить Managed Postgres или Managed Redis, и просматривать логи. Используйте Lizard SDK для создания Sandboxes для выполнения кода. + + + +## Выберите задачу + +| Я хочу… | Начните здесь | +|---|---| +| Развернуть первое приложение | [Быстрый старт приложения](/getting-started) | +| Развернуть Next.js, React, Vue или Python-приложение | [Руководства по фреймворкам](/framework-guides) | +| Развернуть из Claude Code или другого кодинг-агента | [Руководство по кодинг-агентам](/guides/deploy-from-coding-agent) | +| Хостить удалённый MCP-сервер | [Руководство по Remote MCP](/guides/deploy-mcp-server) | +| Держать Telegram-бота запущенным | [Руководство по Telegram-воркеру](/guides/telegram-bot) | +| Подключить базу данных | [Managed Postgres](/addons/postgres) | +| Запускать сгенерированный код в отдельной среде | [Быстрый старт Sandboxes](/sandboxes/quickstart) | +| Сохранять файлы после завершения sandbox | [Persistent Volumes](/sandboxes/volumes) | + + + +## Разверните приложение + +Установите Lizard CLI и войдите, затем разверните репозиторий, к которому у вас есть доступ: + +```bash +npm install -g @lizard-build/cli +lizard login +lizard add -r your-org/your-app +``` + +Lizard собирает образ на своих серверах, поэтому локальный Docker не нужен. [lizardpack](/concepts/build-pipeline) обнаруживает поддерживаемые проекты; проектам со специфическими требованиями к сборке можно использовать явные команды или Dockerfile. Проверьте логи сборки и убедитесь, что URL приложения работает после деплоя. + + + +## Понимайте свои ресурсы + +**Рабочая область** объединяет участников и проекты. **Проект** объединяет сервисы, базы данных и Sandboxes. **Сервис** запускает приложение или воркер. Managed Postgres, Managed Redis и Managed Object Storage предоставляют сервисы данных, к которым приложения подключаются через ссылки на окружение. + +У Apps и Sandboxes разные правила выполнения и хранения. Изучите [лимиты](/platform/limits) и [хранение и восстановление](/platform/storage-and-recovery) перед тем, как полагаться на размер, время жизни или удержание данных ресурса. + + + +## Найдите нужный уровень детализации + +- [Гайды](/guides) охватывают задачу от настройки до проверки результата. +- [Руководства по фреймворкам](/framework-guides) дают команды сборки, адаптеры, порты и проверки для каждого стека. +- [Основные концепции](/concepts/architecture) объясняют проекты, сборки и деплои. +- [Справочник Lizard CLI](/cli) перечисляет команды, флаги и коды выхода. +- [Устранение неполадок](/deploy/troubleshooting/service-never-healthy) помогает диагностировать неудачный запуск. +- [Известные проблемы](/platform/known-issues) фиксируют ограничения и случаи восстановления, которые нужно проверить перед релизом. diff --git a/_locales/ru/manifest.json b/_locales/ru/manifest.json new file mode 100644 index 0000000..b731889 --- /dev/null +++ b/_locales/ru/manifest.json @@ -0,0 +1,576 @@ +{ + "locale": "ru", + "status": "published", + "pages": [ + { + "path": "addons/index.mdx", + "sourceSha256": "a364ec2783f0102fb3067cc844c4db4e6709b3bc522508dea3ccc67aae830ae0", + "translationSha256": "a96fa17f9764146807a47308ffa1f09f52e9704b4b9d568ab6f7816d74724168", + "status": "published" + }, + { + "path": "addons/postgres.mdx", + "sourceSha256": "78346399743959929c09c87d1d98a7e8274d93c1e21a764df94a02b613ac0d09", + "translationSha256": "ac4e37f13d9637fec0ebb156bd307120d72a32a4b3527b03c6cac4e3964a67c3", + "status": "published" + }, + { + "path": "addons/redis.mdx", + "sourceSha256": "5c295a88f06837b2c581b62b2a8787dec1f8da73c77cdf1c8a8b051d5fdd9c19", + "translationSha256": "0a7288c6980c56cededf9eb3f5d7be62880819a78c880a9271d62345a6e3f19f", + "status": "published" + }, + { + "path": "addons/storage.mdx", + "sourceSha256": "60eb80b5a079fc37daa87d064bbb6824ff8061682f54671567389b41ea9a2e3a", + "translationSha256": "dfcd959ebcbf70829e5cb94a1cb441f2c8e6b2a8b5ecbaa885b40f6ac1564eba", + "status": "published" + }, + { + "path": "agents.mdx", + "sourceSha256": "6d12cad052e608f5685ce8a08051d0b5c9d0f0981c06ddf7aa422479f8a6a20a", + "translationSha256": "579354ac44e173fc73ca431fc7a14d6d60c2579caf5b5cc26409dc66f9cfa061", + "status": "published" + }, + { + "path": "cli/add.mdx", + "sourceSha256": "da07da89b28ff85a02dd9afd621d75c935a8e47e26c3bb1bebdeb4fae7d935b7", + "translationSha256": "4d7d13dcc115cba1af4c54be129086feecd9b16c0e044d068bc41261cf63edfb", + "status": "published" + }, + { + "path": "cli/config.mdx", + "sourceSha256": "7ff4c3a6d511e1bf7086f6ea11f47af473c9fd6d15865808bdd0548c265bcd56", + "translationSha256": "3cae362cd7a71dcbbebd1203edaf11c798aa35e27f59f2823db81c31ece596c0", + "status": "published" + }, + { + "path": "cli/docs.mdx", + "sourceSha256": "2f99ebda3a4339d975e1b12c6e8949b4aac33e2b6b4284cfbf5944b274936b83", + "translationSha256": "3e57aa37dc5b9b22a5585ba7b96cb197fcd4313ee5c1809c8db7145f68b0c1d6", + "status": "published" + }, + { + "path": "cli/domain.mdx", + "sourceSha256": "9d4d1e70a6b4078de6486abf9f3f8c679b922e117823232d41df0e403918458f", + "translationSha256": "cb873484c33e37c61a2bdf9affa509fec283d1bd22d7d7b317d81cecd2a09a9e", + "status": "published" + }, + { + "path": "cli/events.mdx", + "sourceSha256": "ce890a024e8b37c7566a3f23d74fe867554aacbcf034103a64d48ba910b4aa4d", + "translationSha256": "70c79a75c1a92c38258f0d9b040427e10e97b4b2fcdf23eec8677ff4f87873a1", + "status": "published" + }, + { + "path": "cli/git.mdx", + "sourceSha256": "d41bde854400c6879516d11f06a0792adad0491f294addcb6a3fbbaca140d2f5", + "translationSha256": "850fec66df668a0b22e52668981afe89b6f12d867e997928f41fd006fd8d62ff", + "status": "published" + }, + { + "path": "cli/index.mdx", + "sourceSha256": "b9f5bb24b661770d8b5fe2916ea43890af08cafc17f32ccd0e49d2e56a0df422", + "translationSha256": "f596accdb860f0159670285d19f78d81ce94577659113aaeba1a7fac6b0e49bf", + "status": "published" + }, + { + "path": "cli/init.mdx", + "sourceSha256": "9ea4e3b5641acc86a3bb0e7013f74cd03df18d64a150858f33cc4220e987cfc7", + "translationSha256": "013cb6249da8b03e45f1a542815ff03fb55d5780073e04ed44638771e8301c22", + "status": "published" + }, + { + "path": "cli/json.mdx", + "sourceSha256": "0db2f5c74b3d7d55b467f5235d38805f5ba531b3b56b60eeb591722b89634798", + "translationSha256": "76511000e89b31bbbdb8da5269178c0cc5e17cfc61996b01732688e51d01ffcc", + "status": "published" + }, + { + "path": "cli/link.mdx", + "sourceSha256": "c830b5269697edcce4a1344de712a26319d60dbb73f9aee71f905da45f301c90", + "translationSha256": "2cccce33c5771ad0c8eed4d15c5ae62d1334bdc5a8f360451de5515fe5b78814", + "status": "published" + }, + { + "path": "cli/login.mdx", + "sourceSha256": "732fd0d32942e45da0f61325478ac2853710161f8d8dd9cbd874b192ddd41220", + "translationSha256": "248deb8e124ef44decb71ce6ae367ba849426322a4bd0b009a89999c721b371a", + "status": "published" + }, + { + "path": "cli/logout.mdx", + "sourceSha256": "a8e49ead7c934a4c29d44421349bd46d3f7f1cc81dbde03ef4350d10cbf12e03", + "translationSha256": "5728cda91eaa40006897c7b4f40be3c248546ee614ecda4937d0fe2ce34bf901", + "status": "published" + }, + { + "path": "cli/logs.mdx", + "sourceSha256": "deebb5f030fb9b3a36000036f9b8f829fc8319cd0c559ebe0f528f175d5eb384", + "translationSha256": "efd019475f3325dace9180d906cb4a250950ff8667bbe43a7261b4bc29122e72", + "status": "published" + }, + { + "path": "cli/metrics.mdx", + "sourceSha256": "dcfa3c003c126ccbc276d2423d5d8fab30adfb685459c4cf546cc53ed02d3429", + "translationSha256": "ce7fa63f70122045a7d0c36f2014afddb0849120e943b4b14d68605c9f5a2be8", + "status": "published" + }, + { + "path": "cli/open.mdx", + "sourceSha256": "34659aaba345efeca309eded62ca791414e7f2cac10aa6a66b1fc81a6adcc7cd", + "translationSha256": "5a9ffd501d0e895355c116159a2ddb3625740ff6a20b0331839eef6f04e774f8", + "status": "published" + }, + { + "path": "cli/port.mdx", + "sourceSha256": "925f588fe174b968738163a0c064af2090b9d4489dd82a75a5b111d8c002f8e8", + "translationSha256": "33cf6c3e898c7d280372c1ad39ee9c6680804db60e6fcf0eb540136fa6c90c10", + "status": "published" + }, + { + "path": "cli/project.mdx", + "sourceSha256": "3cd89738f9965ece2a6ec8158963cfe3d0f118bf81334dde58792ac858890521", + "translationSha256": "048b0f78a73c2e8ee5df276ad64a500d91b10bd47f19a3ef0b60e1334a7dd7ec", + "status": "published" + }, + { + "path": "cli/ps.mdx", + "sourceSha256": "7cae9f4efdd03bd9cc38affa13ce3537d8f6a6cb8ec4a3e12748235a29afb7d1", + "translationSha256": "31cd36d53f858443638bd42a7a1e228e662deb8abcc21963fde4297c6fe3a439", + "status": "published" + }, + { + "path": "cli/redeploy.mdx", + "sourceSha256": "69e3567d19d1eee5ecb88848519c871170982cd8bdae0cc832848425c00976f4", + "translationSha256": "824337767cd6ea0efdd0b322ba1763ad6bf19a603c115b279fbb26585fb3ab89", + "status": "published" + }, + { + "path": "cli/regions.mdx", + "sourceSha256": "fb4374ff44f0cb307cda3b11a32d2af140628aecefcc72648c8bd4fac79a0390", + "translationSha256": "ab6a8e2928569249d07accaa8ba7f5020703a96b202288a5b4864a20d3118db4", + "status": "published" + }, + { + "path": "cli/restart.mdx", + "sourceSha256": "0001cc039c216e29704bc8dd032843f33eeda479e3b936864c55ebb82c19392b", + "translationSha256": "ff2f5447dc339262311ee726905ec062659f795e0276e4bf3a4ea16e6684eb3c", + "status": "published" + }, + { + "path": "cli/run.mdx", + "sourceSha256": "3edbc8067d4e4223e7f8fabab0d031173b096b641134895988c9693bdc10b5d6", + "translationSha256": "5236216d7a1aa28c3cb7d3714e4774674c194d3bf42dfaf3cd619ed70e4253b1", + "status": "published" + }, + { + "path": "cli/scale.mdx", + "sourceSha256": "d0128acc8893d2b40bc7b663fe48867ed247851cddc52817ef2f1a55a97bef5e", + "translationSha256": "9f3b17070e8145716559bc244eb8677deaa503c7d7ec196705204af5e6e8357b", + "status": "published" + }, + { + "path": "cli/secrets.mdx", + "sourceSha256": "635491af6079e6a4f8c718f5443f5b19b9b3e8697957a2917a451631eecf3282", + "translationSha256": "37d360b4fc063a8321a508564ab267a2e2750706cd53378589858ecb32374853", + "status": "published" + }, + { + "path": "cli/service.mdx", + "sourceSha256": "f4a4dedae24ae7928cc0e8279525f80551f1bb01b209beb97254b5966d8ff038", + "translationSha256": "76ca8d64dfb99b9911c183e384f47e87d51a498e8c0397e805cc1fd005f0ea3b", + "status": "published" + }, + { + "path": "cli/skills.mdx", + "sourceSha256": "5ee058f81c64343d5667de9ebd49f1bc975010a25258a74ce92458d638b7731b", + "translationSha256": "c05d42eaf72d714ae4424665677b228ae147f3cf79399cd16a38560eaf2ba7cc", + "status": "published" + }, + { + "path": "cli/ssh.mdx", + "sourceSha256": "f2c1105cca6be5eff87de0249a23d52dd4b5302065b6a0839ba3106669664e46", + "translationSha256": "f636dfc20897e0879db0558b4155bb4b725821d27f10ee84396d36b5c4eb52a0", + "status": "published" + }, + { + "path": "cli/status.mdx", + "sourceSha256": "d1c2b6873e7679bdb11253c71aa03566f64c9d46f30a9de283ac58b42a47af8a", + "translationSha256": "14362c521de882181857379a66f53fd9985896ecc1646ec1a9f733d653471d70", + "status": "published" + }, + { + "path": "cli/unlink.mdx", + "sourceSha256": "e824c1f057db0696eee4b37488cdd43292dbe9d08770112d3e9af9b9ab70a5d6", + "translationSha256": "f71603465ddfaec7d300956d27560c37924cfef0acfd6d943cb3879675eaf58f", + "status": "published" + }, + { + "path": "cli/up.mdx", + "sourceSha256": "8d7512c5e26dbf5a0316437f99e1cc93ce0ebdfe7bf69491636ed767eda36695", + "translationSha256": "1f57ed32035e988c7b171c40888a59ae8d93490392a5907de19d54352d297ffc", + "status": "published" + }, + { + "path": "cli/upgrade.mdx", + "sourceSha256": "1f33d0a46185278e2858d89f7a19e9e57a63d5dd6bd36c66c0f4f348384c8e93", + "translationSha256": "40b1c93220af4e923197ae277fc6c098c2fdd4e74819524d1232a8bf62486e63", + "status": "published" + }, + { + "path": "cli/whoami.mdx", + "sourceSha256": "053bc71c8bd276882bdd10cd64d42ce8e13e500c01424fcfd8e1fd7083b3467d", + "translationSha256": "88e141e267cc2fd4a53e9f8c6b6fee016335da1c0273c8a15438891a12b15a6c", + "status": "published" + }, + { + "path": "cli/workspace.mdx", + "sourceSha256": "bc138c7663e0b4c8ae76c3b2d55c9f72d83fa08fc19f3475d5e7bc08e7da78d2", + "translationSha256": "de5aa157fc755de5a1a1566fd036eb7efc1a7f87dca9c8405f1a8b8223253996", + "status": "published" + }, + { + "path": "concepts/architecture.mdx", + "sourceSha256": "fa5a5aa8a4f23b1d89be99fd3d8db0a9f19831991f9d5fb55730fd12dd399cff", + "translationSha256": "3099f8859785aa3b8b6356f91669bd8c90db2bdd253eec28cc833bd5be02f541", + "status": "published" + }, + { + "path": "concepts/build-pipeline.mdx", + "sourceSha256": "b0ec0991712b3f5ef246a1ec3dea10687a7c592debecec517b6498db2daa4bb3", + "translationSha256": "dd4caa47ab43a30d3c917f5275cacb25ec7dd21312ab4ad26fd354f7c5491668", + "status": "published" + }, + { + "path": "concepts/deployments.mdx", + "sourceSha256": "0f54a580f17b7c807cadebe8b0d6ef9bfd793e8b16486c51c6cffb40a8eb8bba", + "translationSha256": "fb1568c3230a4884b6dda8c5054fb86009d63291b8d7dbbad604a12b04f8e9a4", + "status": "published" + }, + { + "path": "concepts/index.mdx", + "sourceSha256": "92ffb749631fb660c542e40ff875f7cd8aa4849c9d77d06f4ac286578ee58bc4", + "translationSha256": "aecd8e0f52f17b2f8c1af3b9f8c666c77fdcdec677ebe59d2a46a532e368dc41", + "status": "published" + }, + { + "path": "dashboard.mdx", + "sourceSha256": "4fa1240afec8962e3df1c9e564280c83963761f2f64b47502eb8b0d9e9d2ed0c", + "translationSha256": "e5c1886bbd120d638aecacbd06a9817731fa5dc20779b21783719678b5ab2cb2", + "status": "published" + }, + { + "path": "deploy/github.mdx", + "sourceSha256": "697a33210ef14bb34a5074f44847fa69cb7ea169494942fc571e773b200b44c2", + "translationSha256": "9ba246063d6f3ce6df37eea35cd5d7bf31b53d27c4d0ea78f5dc5c7ceee9fc22", + "status": "published" + }, + { + "path": "deploy/index.mdx", + "sourceSha256": "39a4a222ec6cbf55b0d98393646ad7690433e651cc81e3954e85a713157c193f", + "translationSha256": "1b54501ddf8f8f88d0f4df81b58388eb4e1ca6e7e59c5cf2b37c381976d7095c", + "status": "published" + }, + { + "path": "deploy/regions.mdx", + "sourceSha256": "83fc01f4cafa29b368b5bee232de3db69a7fa0c92fd74a6a16381c327005881e", + "translationSha256": "90e4ac631348fbcfef545d8dbc7cf3db3dad4a503ec2ed90b228a4f80cffa511", + "status": "published" + }, + { + "path": "deploy/scaling.mdx", + "sourceSha256": "563e23a94dc6dd4c634c141f4e953dfc97fcc9a2002cf54ba1030e36e3d83748", + "translationSha256": "17e19341026d96cd91a6889a23a773afcd62e3c1641201df7464fe6e3a78e1c3", + "status": "published" + }, + { + "path": "deploy/troubleshooting/double-build.mdx", + "sourceSha256": "1d2254daad7f87e1fbe9e869bd6e0a2f7afbb71ef73e9964e2d2be3b7c011884", + "translationSha256": "47b747d39785d4e50e59cc4732e69bd718ead4b3c55596666729be6c91705da3", + "status": "published" + }, + { + "path": "deploy/troubleshooting/incomplete-dockerfile.mdx", + "sourceSha256": "6f9a46f14284e8c095ef4450973b21b6841073c0b8a959e233e267ff437cc6e0", + "translationSha256": "5e0510cc47715a163173f2856e88248d16aac1a954c1106f6e649fef400977d2", + "status": "published" + }, + { + "path": "deploy/troubleshooting/service-never-healthy.mdx", + "sourceSha256": "9d348e4d46599ed785b0c8d7d906d3672c8ad834114a3d80834467af954e17a8", + "translationSha256": "8aff530616f1d6108c03044b0a03a7163a25398a6b110caf2e2f5e0e81aad116", + "status": "published" + }, + { + "path": "deploy/upload.mdx", + "sourceSha256": "17fc2068ae350b3a6ab7349e29fc908abb1ca8087260c7ed8e0025ec5a053941", + "translationSha256": "4f3d21228c8a1c8de116a7af708a2fccc1701b132de29595649a88ad4d9e8e32", + "status": "published" + }, + { + "path": "deploy/workers.mdx", + "sourceSha256": "43a2bbbb43fb079d035d5cf785f7e6c0536f84ed941e54bc8382a067df0b6fad", + "translationSha256": "0bba999508bc653247caf270f18021607a36a2f0ca8f15fbd0f5644fb912ce8d", + "status": "published" + }, + { + "path": "framework-guides/astro.mdx", + "sourceSha256": "4b89ac3379be48f204f3b932680f0900161e7373ed2436590be3456dd07e6315", + "translationSha256": "e029a2b0ba8610d60e51d86ba7329f17192e56beb12a9cbe2ee071f1ea07e6eb", + "status": "published" + }, + { + "path": "framework-guides/django.mdx", + "sourceSha256": "11422a3685e71d7b95f2055799ca16c9037ebe8a279c1d9c1c891a2dade79440", + "translationSha256": "b998e61d395db2d0a66c4c7d9b1d200ea540f2d1c22d63181124daa8dc98f7a4", + "status": "published" + }, + { + "path": "framework-guides/docusaurus.mdx", + "sourceSha256": "65a0cbde6b2ba696cfb9cc99b45a0c4f7d7d82b24763d82230ede29eb48fe20f", + "translationSha256": "98122c4a349095866c7d4517cda613a789760b5f6e18d2b18c9e49fcced52ff3", + "status": "published" + }, + { + "path": "framework-guides/fastapi.mdx", + "sourceSha256": "9da90747b275c5d3b46aa6827ff7603ec6efb1cc4fffe48836c58d4770f904f8", + "translationSha256": "d46922b1bfa95663957decd832a7bae9cca2be6276a236c0b92bf41e64a38356", + "status": "published" + }, + { + "path": "framework-guides/hugo.mdx", + "sourceSha256": "c552b74cc22994ab2e17d5a0c1eb4afdaf2d00f64960d9581bcf46300f6c202c", + "translationSha256": "90d33f18c2053bcd6e9fdd849844226580f755eedd560a691c84ca16b5909af5", + "status": "published" + }, + { + "path": "framework-guides/index.mdx", + "sourceSha256": "ca924027746d3390d618495318c3fdde147d705193b3e04d30d71ac779c2a33a", + "translationSha256": "68486407acf3ca6e5b490ae5528dc04be223e6af7ad257ff1db8fa595524ade4", + "status": "published" + }, + { + "path": "framework-guides/nextjs/index.mdx", + "sourceSha256": "a30666d082660a9a10e0f8a990b0ac1a476ad16d71c45c3e33d11e8d7f9ed926", + "translationSha256": "1f1a1dea2e64187e668cefa9863e59fae0b2f315b514ffb1f4cbd21a0ab9ffd6", + "status": "published" + }, + { + "path": "framework-guides/nextjs/static-export.mdx", + "sourceSha256": "344b7b0a3c925f9e5f7df53054d3aa1525dd8e0b2c98c2e86fd990fa8309a795", + "translationSha256": "c6fb5181b51959fc4d389dda9bca0c349248ab8a5081398a12138147ea0ff942", + "status": "published" + }, + { + "path": "framework-guides/nuxt.mdx", + "sourceSha256": "edfe7100de75c167475248a291fbb276ab899e4e9aba4aabb37745720b4180ee", + "translationSha256": "0f28a0a108be5bf173f6cfcaa9b0e7b0c6eb5e83d1e7e7d0cddcec8c12821f77", + "status": "published" + }, + { + "path": "framework-guides/react.mdx", + "sourceSha256": "c96a03f9b274d91751231de136d1a37a2554ebcdad8ebffd5b11067c06537c34", + "translationSha256": "ed35d911d86916bea8048ffd56fd438b4974c1bc9762d95b9aa5ac9b151bd257", + "status": "published" + }, + { + "path": "framework-guides/static-routing.mdx", + "sourceSha256": "277dbfc3d581d2ba332fe183807134aca7084876648a0aca7cb4b7cf227caf43", + "translationSha256": "e411103a551d1f95e6fcb3ac94bfcf21afb85e7e2cb92d2e3ceeb76ceffbd63b", + "status": "published" + }, + { + "path": "framework-guides/sveltekit.mdx", + "sourceSha256": "eb98e0ae2bcc536998735b23d6d28ea658fce42e1139c78d3eb4570a54347d52", + "translationSha256": "e0059fc46d77504bb4ffee4b40c0714d7a30b9ff7faeae8dcb41d2a4bd2bc10d", + "status": "published" + }, + { + "path": "framework-guides/validation.mdx", + "sourceSha256": "068375b554451b4be0aa21b2ea7d53789e61e44cd592947877cce6223240f26f", + "translationSha256": "43b6ad2571b5c844d37186c3d912b97f60bf18601442a98d8e16fe836ce768bf", + "status": "published" + }, + { + "path": "framework-guides/vitepress.mdx", + "sourceSha256": "5e3d98d5d3e2dcbb5af644fb500e39389e216efe772eda2933aa291384aebda4", + "translationSha256": "16abeb12a9497b4f39343c979b44f81935a84546815b69dc7269d2024cbe54a7", + "status": "published" + }, + { + "path": "framework-guides/vue.mdx", + "sourceSha256": "442bd3f20789c9c6243ed364d8e4c350efebeb33a289334ee5222c9047217098", + "translationSha256": "9653fde5f5f1cbcd39be3757cb30ea1cd509f016d9848b1f85fb433dac5c86c1", + "status": "published" + }, + { + "path": "getting-started.mdx", + "sourceSha256": "34aa52cecefcc9a9ef34f3eb6586c8cd42de7cad388916e983aabc31c77a1527", + "translationSha256": "9f6b8e33b0ca85519da7eca85bbe23c30425c02b23a2a38f6f5df43f8b19e8a8", + "status": "published" + }, + { + "path": "guides/deploy-from-coding-agent.mdx", + "sourceSha256": "446afe16553138fce16e5ee5aba6c52f600eb9d7f3b326f8822eabbec56ea734", + "translationSha256": "bf931439a3b03a3d9aa32821c55ed3c710f3b6c35b3482a9c0ac0eee174e8551", + "status": "published" + }, + { + "path": "guides/deploy-mcp-server.mdx", + "sourceSha256": "55f7aea7cf3929bb84cd7ad4b67c1feb52cc707d888ec00fa2a7fe702d417738", + "translationSha256": "a6f1687fcf258725aaeaeb02059c8cb6d2936af3424582faaddaa0de7970e575", + "status": "published" + }, + { + "path": "guides/flowise.mdx", + "sourceSha256": "fa697aec8657e3ea920d1c88a6095ff442064a0ab3c0a812f10e5e5c5c1ee1b6", + "translationSha256": "95e7f73ddacc9a1f1da9f7c75e5876cdc7c2cc9f2c782b5e639c1440344cbc96", + "status": "published" + }, + { + "path": "guides/index.mdx", + "sourceSha256": "6492dcbd87273f0bc2148b1b3cf3e787ce4873932c2b270d11685f8984615ac6", + "translationSha256": "a88406d64a7c52f49f157f1fd84917e5b6bbc6bba9975de0f038c6aab24074bb", + "status": "published" + }, + { + "path": "guides/telegram-bot.mdx", + "sourceSha256": "db7b0a93dbae68b767e93022e99d2684dc7f8881bb4060cc2743c2f95742510a", + "translationSha256": "f9342991330c2a5dfcfed6ef5e5afbd02a7bb9b2d0625c28affef1a4611dd8fa", + "status": "published" + }, + { + "path": "guides/umami.mdx", + "sourceSha256": "60ac58aa3f74b7b22f7a29c2dabb1040983ffb9635ec0364bea5f4eeb9a1a184", + "translationSha256": "c2b668e791d03fae832146338f482672064e16a84d4d9d88ce65c07b60d1d36b", + "status": "published" + }, + { + "path": "guides/validation.mdx", + "sourceSha256": "f060ee682789b323ce18e0f282ba6bb47a85accc912583a7600e69546dd9aeed", + "translationSha256": "6abc1d6b0ea137b0edcf274886d702b594ab8e2d7a4cdef819b492cc299389b3", + "status": "published" + }, + { + "path": "index.mdx", + "sourceSha256": "45b40d974470539641750f9473f39a6af74fbf999f39e8fb924c867abcc18370", + "translationSha256": "df4c6259a1a48b664777326445e072bf8963ebfa7c037f43f020c428ea68338c", + "status": "published" + }, + { + "path": "networking.mdx", + "sourceSha256": "cf23c1a1df8c7e4b7835590d38786dc0574de771374c42dea5c1f5fdfc0079fd", + "translationSha256": "fb948a53177b262f9c2915fd8202e7c53d2643e08becb8046ef846ace8672695", + "status": "published" + }, + { + "path": "observability/events.mdx", + "sourceSha256": "db2092362e0139e9ef1b6816eafd3f90ecfca59faad01fe1dfe0383057ce6bdb", + "translationSha256": "0af5c73e11c34074fc3313560939b128f96e7ed0c5b946d73a97ae4406e6a460", + "status": "published" + }, + { + "path": "observability/index.mdx", + "sourceSha256": "c99b35a322a98276ae9759c2443b7e1ebb77bb2a07b15391d6eff2d4e0d59fd1", + "translationSha256": "1c4ea72fb517830a7aa9a5b0098471cb954f4cdf429521017310eb27f8aedb34", + "status": "published" + }, + { + "path": "observability/logs.mdx", + "sourceSha256": "9e1e57fcde78990342ebd7619a1d5762f15dfb35c95142885f8c561bb9e35d40", + "translationSha256": "22fe6105fd1c32ef4d783a1828efe7aaf24890b2334a4dfdab5b9a948d5a477b", + "status": "published" + }, + { + "path": "observability/metrics.mdx", + "sourceSha256": "f95728b789c693cc7de9e37c2e8b07e8e35a8129fa754ac7aa8c296b97a7364a", + "translationSha256": "0b3b668100512c3304e9a23dbfad5e1cb51528140c0a0843071579060edad6e5", + "status": "published" + }, + { + "path": "platform/billing.mdx", + "sourceSha256": "a93fe73b92ee9d775f4b3e8182db6b719f6a1e8fa988b9f0a482eb5e24d29c62", + "translationSha256": "65693ec61d5155ec8a60df8e6b92a88430f5fd48ce78b3618f44318ae523fc15", + "status": "published" + }, + { + "path": "platform/known-issues.mdx", + "sourceSha256": "d9d69003cc9345a6059440d9f03894ceb437d7173be215e95403ba9b9210aec0", + "translationSha256": "05b4a2e8a6b77b2619750b0e0c8361286e24fc3e85c9b1553e015f8ec0b14ddb", + "status": "published" + }, + { + "path": "platform/limits.mdx", + "sourceSha256": "5f2166c38b61c6dc032b4f0e4ac1fc1ae2c8a14db9af49ffd2371a7bf4649214", + "translationSha256": "526853dffee48724b245fc68b7eb778944d4812a9d53ab4e596f55e1cca70e33", + "status": "published" + }, + { + "path": "platform/storage-and-recovery.mdx", + "sourceSha256": "30a114b2f76b0d2bbcf67cdd2a07630ef1c3992a526aa8915ca30a63d0ba18d4", + "translationSha256": "deaff38bfc0e371e7d94a3e3294ebfa6d019ba394a380a48d8c226779ad4f540", + "status": "published" + }, + { + "path": "sandboxes/code-interpreter.mdx", + "sourceSha256": "d187221290fdbba78567a330e562a618cdd7d9fff31cc32c74b7ed9c1c67f241", + "translationSha256": "abf8778395d1ef5be3f81b0b0647cbd3f268bd650a44fae8d946f42b28ed23a5", + "status": "published" + }, + { + "path": "sandboxes/dashboard.mdx", + "sourceSha256": "828415eb0c46fce33f20bc2dae780262eacabf58127a590b1d681d54966db527", + "translationSha256": "46a48b003b3205f404113fecd59595cea249a978fe8c2f67ff28ecc2b452fe30", + "status": "published" + }, + { + "path": "sandboxes/index.mdx", + "sourceSha256": "f07dd490dcb4e1b5376d256de65e13d79a37688fb8286b2dd6578e0eb14fdfbb", + "translationSha256": "de6588e561b7b7e2ff1b73fa0988f5a2ae404c548a65644794b45c86d997510f", + "status": "published" + }, + { + "path": "sandboxes/quickstart.mdx", + "sourceSha256": "c58f024fe163b5142bf554232363ffd74fce365d54cebc2f14ae997f9ab210dd", + "translationSha256": "38321ddc4a522eacafc1ed96c725d9f68895246fadb1f703179fba1a10ff7c38", + "status": "published" + }, + { + "path": "sandboxes/sdk-reference.mdx", + "sourceSha256": "2ef3c1a78d607f5daec121d792e10e66b25dc62538da865aaed3cc69a1947bd9", + "translationSha256": "61dfe48e131226bae8ed17bf774668bd87ee6631bb2812c58c55dd588f53e44e", + "status": "published" + }, + { + "path": "sandboxes/volumes.mdx", + "sourceSha256": "335158c3113ae1afa8cf0c966ffb5390d4e52b4e21965058318be124b5235438", + "translationSha256": "ffbc04f60b3247c288d7c4db5fc38773c3cfc40c576078258c04cdd22e90d9ec", + "status": "published" + }, + { + "path": "studio/getting-started.mdx", + "sourceSha256": "3d6df5a941a22427bf6146f91cf795ceac7439aaf86d8c2d1213dcd3ba8ba2ae", + "translationSha256": "1583ba5fae37c516d3de4c0d5adcd6a636014d198894ec84f28cbab5e9a72143", + "status": "published" + }, + { + "path": "variables/index.mdx", + "sourceSha256": "2b605e838fc7dc268894a433dd4dfea5f3aa9b786ee80b334f9ae9edb242400c", + "translationSha256": "7a2ddafc1a3dcb9720f133360961ac0a16017822b06e68ed451194091f8e6c07", + "status": "published" + }, + { + "path": "variables/references.mdx", + "sourceSha256": "21300a1c62e7d69d9bd9c935f95985ad1dc03fd5085ab6b862749b178f34f89c", + "translationSha256": "718599ae3075ecfa7b79153724d10988304756fb4c31c751783f76daf55e39c2", + "status": "published" + }, + { + "path": "variables/troubleshooting/reference-not-applied.mdx", + "sourceSha256": "2be66a188aa38cb545bd36437c19d928f70eedab58c3b38a7a2ae7720c5f25fa", + "translationSha256": "c78e5fa60b37b19cbd36d31a6c083014ace5fa44dbc91091e69dd482f5616fe8", + "status": "published" + } + ] +} diff --git a/_locales/ru/networking.mdx b/_locales/ru/networking.mdx new file mode 100644 index 0000000..a7f0dff --- /dev/null +++ b/_locales/ru/networking.mdx @@ -0,0 +1,85 @@ +--- +description: "Каждому сервису выдается домен onlizard.com с автоматическим TLS. Подключите собственный хостнейм, верифицируйте DNS, пробросьте порт или удалите домен." +--- + + + +# Сетевое взаимодействие + +Каждому сервису в момент деплоя выдается сгенерированный `*.onlizard.com` домен с автоматическим TLS, независимо от региона. Подключите свой хостнейм, когда будете готовы выйти в прод. + + + +## Сгенерированные домены + +Сервису автоматически создается домен по умолчанию. Посмотреть его (или сгенерировать новый): + +```bash +lizard domain # show the service's current domain +lizard domain generate # generate a new *.onlizard.com subdomain +``` + +Объектное хранилище, обслуживаемое через [S3-аддон](/addons/storage), использует региональный шлюз (`s3-.onlizard.com`) вместо стандартного домена. + + + +## Подключение собственного домена + +Хостнейм — это **позиционный аргумент**, отдельного `add` подкоманды не существует: + +```bash +lizard domain app.example.com --service web +``` + +Lizard вернет DNS-записи, которые нужно создать (`CNAME` для хостнейма и `TXT` для верификации). Добавьте их у своего DNS-провайдера. + + + +## Верификация + +После распространения DNS активируйте домен: + +```bash +lizard domain verify app.example.com +``` + +Команда проверяет `TXT` запись и активирует домен. TLS подготавливается автоматически. + + + +## Удаление домена + +```bash +lizard domain delete app.example.com +lizard domain rm app.example.com --yes # alias, skip confirmation +``` + + + +## Проброс конкретного порта + +Если сервис слушает нестандартный порт, подключите домен к этому порту: + +```bash +lizard domain app.example.com --service web --port 8080 +``` + + + +## Worker-сервисы + +У [сервисов в режиме worker](/deploy/workers) (`containerPort=0`) может всё равно отображаться сгенерированный домен, но он ничего не обслуживает — слушателя и маршрута балансировщика нет. Не подключайте собственный домен к worker-сервису. + + + +## Управление в дашборде + +Раздел **Домены** в дашборде (`lizard open`) показывает статус верификации и TLS для каждого домена, а также позволяет визуально добавлять или удалять хостнеймы. + + + +## См. также + +- [`lizard domain`](/cli/domain) — полная справка по командам. +- [Регионы](/deploy/regions) — размещение сервисов и аддонов в одном регионе для низкой задержки. +- [От прототипа к SaaS, за который платят](https://lizard.build/blog/google-antigravity-how-to-deploy-your-app-to-production#from-vibe-coded-prototype-to-a-saas-people-pay-for) — где собственный домен стоит среди прочих вещей, которые всё ещё нужны сгенерированному приложению. diff --git a/_locales/ru/observability/_meta.ts b/_locales/ru/observability/_meta.ts new file mode 100644 index 0000000..c694f86 --- /dev/null +++ b/_locales/ru/observability/_meta.ts @@ -0,0 +1,6 @@ +export default { + index: "Обзор", + logs: "Логи", + metrics: "Метрики и стоимость", + events: "События и история", +}; diff --git a/_locales/ru/observability/events.mdx b/_locales/ru/observability/events.mdx new file mode 100644 index 0000000..eee2c2f --- /dev/null +++ b/_locales/ru/observability/events.mdx @@ -0,0 +1,45 @@ +--- +description: "Read a service's deploy timeline and live replica status with lizard events, and find the same history in the dashboard's Развертывания view." +--- + +# Events & History + +`lizard events` показывает историю развёртываний сервиса и текущий статус его реплик — хронологию того, что было выпущено, и что работает прямо сейчас. + + + +## Просмотреть события + +```bash +lizard events # deploy history + replica status +lizard events --service api # a specific service +lizard events --limit 25 # show more entries (default 10) +``` + +Каждая запись охватывает действие развёртывания или масштабирования и получившийся статус реплик, чтобы вы могли мгновенно ответить на вопрос «что изменилось и здорово ли это?». + + + +## Быстрый статус + +Для быстрого обзора всех сервисов в проекте — статус и URL — используйте: + +```bash +lizard ps +lizard status # the current directory's workspace/project/service link +``` + + + +## Панель управления + +Представление **Развертывания** в дашборде (`lizard open`) отображает ту же историю в виде таймлайна, с панелью деталей для каждого развёртывания (логи сборки, коммит, статус) и здоровьем по репликам. + + + +## См. также + +- [Развертывания](/concepts/deployments) — жизненный цикл развёртывания. +- [Логи](/observability/logs) — логи рантайма, сборки и перезапусков. +- [Metrics & Cost](/observability/metrics) — использование ресурсов и биллинг. +- [`lizard events`](/cli/events) — полная справочная по командам. diff --git a/_locales/ru/observability/index.mdx b/_locales/ru/observability/index.mdx new file mode 100644 index 0000000..08d3a1d --- /dev/null +++ b/_locales/ru/observability/index.mdx @@ -0,0 +1,19 @@ +--- +description: "Узнайте, что делают ваши сервисы: смотрите логи в реальном времени, отслеживайте метрики и расходы, просматривайте историю деплоев и реплик." +--- + + + +# Наблюдаемость + +Узнайте, что делают ваши сервисы: смотрите логи в реальном времени, отслеживайте метрики и расходы, просматривайте историю деплоев и реплик. + + + +## В этом разделе + +- [Логи](/observability/logs) — логи в реальном времени и исторические, включая логи сборки и перезапуска. +- [Metrics & Cost](/observability/metrics) — использование ресурсов и их стоимость. +- [Events & History](/observability/events) — временная шкала деплоев и статус каждой реплики. + +Каждое представление здесь также имеет форму `--json`, которую читает AI-агент при сбое деплоя — см. [развёртывание из Claude Code](https://lizard.build/blog/deploy-from-claude-code). diff --git a/_locales/ru/observability/logs.mdx b/_locales/ru/observability/logs.mdx new file mode 100644 index 0000000..45b4a0c --- /dev/null +++ b/_locales/ru/observability/logs.mdx @@ -0,0 +1,73 @@ +--- +description: "Потоковое вещание логов времени выполнения, чтение логов сборки после неудачного деплоя и получение хвоста логов вокруг перезапуска через CLI или панель управления." +--- + + + +# Логи + +Lizard захватывает **логи времени выполнения**, **логи сборки** и хвост логов вокруг **перезапусков**. Смотрите их в реальном времени в терминале или просматривайте в панели управления. + + + +## Логи времени выполнения + +```bash +lizard logs # last 200 runtime lines, then live tail +lizard logs --service api # a specific service +lizard logs --tail 1000 # more history (max 1000) +lizard logs --level error # filter by level +``` + + + +### Поведение с `--json` + +`lizard logs --json` **не** является потоком — он возвращает последние 200 строк (переопределить можно через `--tail N`, максимум 1000) и завершает работу. Используйте его для снимков и скриптов. Для интерактивного потока используйте команду без `--json`. + + + +## Логи сборки + +```bash +lizard logs --build # the most recent build's logs +``` + +Это первое, что нужно проверить при неудачном деплое — прочтите, устраните причину, затем `lizard redeploy`. См. [Конвейер сборки](/concepts/build-pipeline). + + + +## Логи перезапуска / аварийного завершения + +Когда реплика аварийно завершается или перезапускается, получите окружающий хвост логов: + +```bash +lizard logs --restart latest # the most recent restart +lizard logs --restart # a specific restart +lizard logs --restarts # list recent restarts +``` + + + +## Листание истории + +`lizard service logs` поддерживает постраничную навигацию по старым окнам: + +```bash +lizard service logs --service api --tail all # full history (no follow) +lizard service logs --service api --page 2 # older window (implies --tail 200) +``` + + + +## Панель управления + +Панель управления (`lizard open`) транслирует логи времени выполнения и сборки с поиском и фильтрами по уровню, и показывает вывод сборки для каждого деплоя в представлении **Развертывания**. + + + +## См. также + +- [`lizard logs`](/cli/logs) — полный справочник команд. +- [События и история](/observability/events) — история деплоев и статус реплик. +- [Деплой из Claude Code](https://lizard.build/blog/deploy-from-claude-code) — логи, написанные для чтения агентом, а не только человеком. diff --git a/_locales/ru/observability/metrics.mdx b/_locales/ru/observability/metrics.mdx new file mode 100644 index 0000000..c9f7293 --- /dev/null +++ b/_locales/ru/observability/metrics.mdx @@ -0,0 +1,50 @@ +--- +description: "Отслеживайте CPU, память, сеть и диск для сервиса, узнайте стоимость текущего масштаба и действуйте на основе метрик." +--- + + + +# Метрики и стоимость + +Отслеживайте CPU, память, сеть и диск для сервиса — и узнавайте, во что это обходится — из CLI или дашборда. + + + +## Просмотр метрик + +```bash +lizard metrics # CPU / memory / network / disk +lizard metrics --service api # a specific service +lizard metrics --range # time window +lizard metrics --watch # live-updating view +``` + + + +## Включить стоимость + +```bash +lizard metrics --cost +``` + +Добавляет данные о стоимости рядом с использованием ресурсов, чтобы вы видели цену текущего масштаба. + + + +## Дашборд + +На дашборде (`lizard open`) эти данные отображаются в виде графиков в разделе **Metrics / Наблюдаемость**, а в разделе **Использование** представлен разбор потребления и биллинга по проекту. Откройте его командой: + +```bash +lizard open +``` + + + +## Действия на основе метрик + +- Высокая нагрузка на CPU/память → увеличьте масштаб: `lizard scale --service api --cpu 2 --memory 2048`. +- Постоянная нагрузка → добавьте реплики: `lizard scale --service api --replicas 3`. +- Нехватка диска на аддоне → увеличьте хранилище: `lizard scale --service postgres --storage 8192`. + +См. [Scaling](/deploy/scaling). diff --git a/_locales/ru/platform/_meta.ts b/_locales/ru/platform/_meta.ts new file mode 100644 index 0000000..7e6e431 --- /dev/null +++ b/_locales/ru/platform/_meta.ts @@ -0,0 +1 @@ +export default { billing: "Оплата и баланс", limits: "Лимиты", 'storage-and-recovery': "Хранилище и восстановление", 'known-issues': "Известные проблемы" }; diff --git a/_locales/ru/platform/billing.mdx b/_locales/ru/platform/billing.mdx new file mode 100644 index 0000000..19dab77 --- /dev/null +++ b/_locales/ru/platform/billing.mdx @@ -0,0 +1,63 @@ +--- +description: "Оплата по факту использования Lizard: тарифы на ресурсы, средства на балансе, автопополнение, комиссии и последствия нулевого баланса." +--- + + + +# Оплата по факту использования + +У Lizard нет ежемесячной подписки или платы за место для стандартных аккаунтов. Пополните баланс и платите только за используемые ресурсы. Неизрасходованные приобретённые средства остаются на балансе, поэтому тихий месяц не требует покупки нового пакета. + + + +## Тарифы на ресурсы + +Цены указаны в долларах США. + +| Ресурс | Тариф | +| --- | ---: | +| CPU | $0.000006948 за vCPU-секунду | +| Память | $0.000003474 за ГБ-секунду | +| Persistent Volumes | $0.000000054 за ГБ-секунду | +| Managed Object Storage | $0.0135 за ГБ-месяц | +| Исходящий трафик | $0.045 за ГБ, с первого байта | + +Входящий трафик не тарифицируется. Apps, Managed Postgres, Managed Redis и Sandboxes используют те же тарифы на применимые ресурсы. Лимиты ресурсов аккаунта всё равно действуют; пополнение баланса не повышает эти лимиты. + +Например, один vCPU и 1 ГБ памяти, используемые в течение часа, обойдутся в $0.0375192 за вычисления. Стоимость хранения, исходящего трафика и комиссии за оплату могут увеличить эту сумму. Это пример стоимости ресурсов, а не сумма списания при пополнении. + +Полное предложение см. в [актуальных ценах](https://lizard.build/pricing). Корпоративное выставление счетов регулируется вашим контрактом. + + + +## Баланс аккаунта + +Использование ресурсов в рабочем списывается с баланса владельца аккаунта. Добавление участников не влечёт плату за место. Страница «Баланс» показывает текущие средства, покупки и средства с истекающим сроком действия. + +- **Приобретённые средства не истекают.** Они не сбрасываются каждый месяц. +- **Пробные средства имеют срок действия.** Новые аккаунты получают $10 пробных средств, действующих 31 день. +- **Промо-средства могут иметь срок действия.** Проверяйте условия и дату окончания, указанные для конкретного гранта. + +Приобретённый баланс оплачивает использование; это не скидка на тариф ресурса. Не вычитайте его повторно при сравнении затрат с другим провайдером. + + + +## Пополнение и комиссии + +Откройте «Баланс» в настройках аккаунта, чтобы добавить средства. Перед подтверждением экран пополнения показывает минимальную сумму, зачисляемую сумму, комиссию за оплату и итоговую списываемую сумму. Минимальная сумма пополнения — не ежемесячная плата. + +Автопополнение — опционально. Установите порог баланса и сумму в настройках «Баланс». Там же можно его отключить. Отключение автопополнения не останавливает ресурсы и не прекращает списание за их использование. + + + +## Низкий или нулевой баланс + +Lizard предупреждает, когда баланс становится низким. Если баланс истощается и оплата не восстанавливает его, создание ресурсов может быть ограничено, а запущенные сервисы — приостановлены после истечения применимого льготного периода. Проверяйте страницу «Баланс» на предмет условий аккаунта и восстанавливайте баланс до конца льготного периода, чтобы избежать приостановки. + + + +## Бездействующие приложения и хранимые данные + +Приложение может потреблять память и CPU даже без запросов. Остановите приложение, чтобы прекратить списание за вычисления. Persistent Volumes и Managed Object Storage продолжают накапливать плату за хранение, пока вы храните данные, в том числе когда приложение остановлено. + +Прежде чем удалять данные, ознакомьтесь с разделом [хранение и восстановление](/platform/storage-and-recovery). В разделе [метрики](/observability/metrics) можно сравнить настроенные лимиты с фактическим использованием. diff --git a/_locales/ru/platform/known-issues.mdx b/_locales/ru/platform/known-issues.mdx new file mode 100644 index 0000000..aeb07a7 --- /dev/null +++ b/_locales/ru/platform/known-issues.mdx @@ -0,0 +1,51 @@ +--- +description: "Текущие нюансы жизненного цикла Sandboxes, ограничения восстановления деплоя и приоритет настроек сборки, которые нужно проверить перед тем, как полагаться на рабочий процесс." +--- + + + +# Известные проблемы + +На этой странице зафиксировано поведение, требующее внимания или проверенного релиза. Исправление кода на этапе ревью не гарантирует поведение работающего сервиса. + + + +## Пауза и истечение срока Sandboxes + +Пауза предназначена для заморозки оставшегося времени жизни. Конфликт между часами узла и отдельным процессом очистки может завершить приостановленный Песочница после его первоначального дедлайна. Перезапуск node-agent и возобновление Песочница без срока истечения также требуют исправления жизненного цикла. + +Пока это исправление не пройдёт живой тест и не достигнет вашего региона, не полагайтесь только на паузу для долгосрочного сохранения состояния. Сохраняйте файлы в `/data` на Persistent Том, либо храните состояние приложения в базе данных или объектном хранилище. Память хоста не является бэкапом. Используйте явный срок жизни и освобождайте Песочница по завершении задачи. + + + +## Redeploy — это не откат + +`lizard redeploy` повторно собирает выбранный исходный код с текущей конфигурацией. Он не выбирает предыдущую сборку. Неудачная сборка и неудачный запуск имеют разные последствия; изучите активный сервис и его логи перед выбором шага восстановления. Не предполагайте, что любой рантайм продолжает отдавать старый релиз при неудачном запуске. + + + +## Приоритет Dockerfile + +Явные команды сборки или запуска имеют приоритет над Dockerfile репозитория. Очистите эти переопределения при выборе `dockerfilePath`. Обновление настроек само по себе может запустить сборку, поэтому проверяйте события перед отправкой очередного redeploy. См. [Устранение неполадок Dockerfile](/deploy/troubleshooting/incomplete-dockerfile). + + + +## Шаблоны и MCP + +Текущий API создания Sandboxes принимает два встроенных шаблона. Инструкции по использованию `lizard push` для пользовательских шаблонов не соответствуют текущему публичному CLI. + +Lizard Skill использует Lizard CLI. Этот рабочий процесс не предоставляет MCP-транспорт. Развёртывание собственного удалённого MCP-сервера — это отдельное развёртывание приложения; см. [руководство](/guides/deploy-mcp-server). + + + +## Изменения порта сервиса: исправлено и проверено 2026-09-09 + +Проверка 7 сентября обнаружила HTTP 503 после смены порта у сервиса загрузки с `3000` на `80`, несмотря на готовый процесс. Продакшн-исправление теперь применяет выбранный порт к работающему сервису и сохраняет явный порт при загрузке и пересборке. Живая проверка смены порта прошла 9 сентября. Проверяйте публичный URL после деплоя, а также состояние сервиса. + + + +## Архивы загрузки и коды выхода при неудачной сборке: исправлено + +Lizard CLI 0.3.95 исключает метаданные macOS `._*` из загружаемых исходников и возвращает ненулевой код выхода при неудачных облачных сборках. Обновите более старые версии CLI; `COPYFILE_DISABLE` больше не нужен. [Проверки фреймворков](/framework-guides/validation) охватывают загрузки с macOS при использовании актуального CLI. + +Успешная сборка сама по себе не доказывает, что приложение работает. Проверяйте публичный URL, маршруты, формы и операции с данными после деплоя. diff --git a/_locales/ru/platform/limits.mdx b/_locales/ru/platform/limits.mdx new file mode 100644 index 0000000..9fdcb57 --- /dev/null +++ b/_locales/ru/platform/limits.mdx @@ -0,0 +1,49 @@ +--- +description: "Проверьте лимиты реплик приложений, ресурсы Sandboxes и тайм-ауты, регионы, а также объём квот аккаунта перед развёртыванием." +--- + + + +# Лимиты + +Лимиты зависят от ресурса, тарифа и аккаунта. Настройка на реплику — это не общий объём, доступный сервису или аккаунту. Проверьте текущий тариф и результат запроса на создание или масштабирование перед подбором размера рабочей нагрузки. + + + +## Приложения + +| Настройка | Область | Что проверить | +|---|---|---| +| CPU и память | Каждая реплика | У трёх реплик с потолком 2 vCPU / 2 GiB общий настроенный потолок составляет 6 vCPU / 6 GiB. Это не прогноз использования. | +| Количество реплик | Сервис и тариф | API принимает 1–10; лимиты тарифа могут сузить этот диапазон. Стандартный тариф разрешает 1, для Pro/Enterprise — 5, с возможными переопределениями на уровне аккаунта. | +| Общий лимит ресурсов аккаунта | Владелец аккаунта | Второй проект не обязательно создаёт вторую квоту. Уточните действующий лимит аккаунта перед планированием крупного развёртывания. | +| Режим воркера | Сервис | `containerPort=0` работает без приёма HTTP-запросов и публичного маршрута балансировщика нагрузки. | +| Пользовательский домен | Имя хоста | Поддомены с wildcard не принимаются. Используйте конкретное имя хоста и пройдите проверки владения и DNS. | + +Приложения могут использовать разные рантаймы. Не предполагайте, что у каждого приложения та же граница микро-VM Firecracker, что и у Sandboxes. + +## Sandboxes + +| Настройка | Текущий Create API | +|---|---|---| +| CPU и память | 4 vCPU / 4096 MiB | +| Шаблоны | `base`, `code-interpreter-v1` | +| Время жизни Raw API по умолчанию | `timeoutMs: 0`, без истечения | +| Время жизни Lizard SDK по умолчанию | 300000 мс, пять минут | +| Диапазон явного времени жизни | Целое число миллисекунд от 0 до 2147483647 | +| Обновление времени жизни | Не менее 1000 мс; это не таймер бездействия | +| Подключение персистентного тома | Одновременно одному Песочница, на узле тома | + +Передавайте явное время жизни из скриптов. Например, `--timeout 300000` делает предполагаемый лимит понятным для всех выпусков Lizard CLI. См. [приостановку и истечение](/platform/known-issues#sandbox-pause-and-expiration) перед тем, как оставлять сессию без внимания. + + + +## Регионы + +Текущие настроенные регионы включают US East (Virginia), `us-east-1`, и EU West (Limburg), `eu-west-lim-a`. Наличие региона в каталоге не гарантирует доступную вместимость для каждого ресурса. Проверяйте выбор региона при создании ресурса; Песочница с существующим томом должен запускаться на узле этого тома. + + + +## Перед увеличением масштаба + +Проверьте активный тариф, настройки на реплику, лимит аккаунта, лимит подключений к базе данных и рост хранилища вместе. Используйте [масштабирование](/deploy/scaling), [метрики](/observability/metrics) и [цены](https://lizard.build/pricing), чтобы сравнить настроенную вместимость с измеренным использованием. diff --git a/_locales/ru/platform/storage-and-recovery.mdx b/_locales/ru/platform/storage-and-recovery.mdx new file mode 100644 index 0000000..d18d161 --- /dev/null +++ b/_locales/ru/platform/storage-and-recovery.mdx @@ -0,0 +1,53 @@ +--- +description: "Выбирайте хранилище для данных приложения и файлов песочницы. Понимайте механизмы подключения, сбои хоста, экспорт и восстановление перед удалением или заменой ресурса." +--- + + + +# Хранилище и восстановление + +Выбирайте хранилище в зависимости от данных, которые должны выжить при перезапуске процесса, новом развёртывании или сбое хоста. Это разные события. Постоянное хранилище само по себе не даёт резервную копию, точку восстановления или высокую доступность. + +| Данные | Где хранить | Граница | +|---|---|---| +| Записи приложения | Managed Postgres или другая база данных | Перезапуск отличается от восстановления удалённых или повреждённых данных. Протестируйте отдельный путь экспорта и восстановления. | +| Данные кэша и очередей | Managed Redis | Решите, может ли нагрузка восстановить своё состояние или нужен собственный план восстановления. | +| Файлы, общие для приложений | Managed Object Storage | Установите политику доступа бакета перед загрузкой приватных данных. Автоматически создаваемый бакет `default` имеет публичный доступ на чтение. | +| Файлы, нужные для последующих Sandboxes | Persistent Volumes, подключаемые в `/data` | Одновременно только одно подключение песочницы; том остаётся на своём узле. | +| Временные файлы песочницы | Гостевая файловая система вне `/data` | Не ожидайте их после завершения песочницы или замены гостя. | +| Состояние приостановленного процесса | Память хоста | Пауза — не устойчивый снимок; сбой хоста лишает это состояние. | + + + +## Сохраняйте файлы после завершения песочницы + +Создайте Persistent Том в том же проекте, подключите его при создании песочницы и пишите в `/data`. Завершите первую песочницу перед подключением тома к следующей. См. [полный пример](/sandboxes/volumes). + + + +## Планируйте восстановление базы данных + +Перед миграцией или релизом, меняющим данные: + +1. Выберите метод экспорта для используемой базы данных и версии. +2. Храните экспорт отдельно от изменяемого ресурса. +3. Восстановите в отдельную тестовую базу и проверьте, что приложение может её прочитать. +4. Зафиксируйте длительность восстановления и самые свежие данные, вошедшие в экспорт. + +Не полагайтесь на запланированные бэкапы, восстановление к точке во времени, многоузловую репликацию или гарантии времени восстановления от управляемой базы данных. Подтвердите текущее соглашение об уровне сервиса и доступные средства управления для вашего ресурса. + + + +## Ссылки на окружение + +Приложение должно читать подключение к базе из ссылки на окружение. Строка подключения — это секрет; не выводите её для проверки обновления. Проверка подключения, например `SELECT 1`, доказывает больше, чем просто видимость переменной в оболочке. + + + +## Связанные руководства + +- [Managed Postgres](/addons/postgres) +- [Managed Redis](/addons/redis) +- [Managed Object Storage](/addons/storage) +- [Persistent Volumes](/sandboxes/volumes) +- [Восстановление развёртывания](/concepts/deployments#failed-releases-and-recovery) diff --git a/_locales/ru/sandboxes/_meta.ts b/_locales/ru/sandboxes/_meta.ts new file mode 100644 index 0000000..0c18e5c --- /dev/null +++ b/_locales/ru/sandboxes/_meta.ts @@ -0,0 +1,8 @@ +export default { + index: "Обзор", + quickstart: "Быстрый старт", + 'sdk-reference': "Справочник SDK", + 'code-interpreter': "Интерпретатор кода", + volumes: "Persistent Volumes", + dashboard: "Панель управления", +}; diff --git a/_locales/ru/sandboxes/code-interpreter.mdx b/_locales/ru/sandboxes/code-interpreter.mdx new file mode 100644 index 0000000..e823cf6 --- /dev/null +++ b/_locales/ru/sandboxes/code-interpreter.mdx @@ -0,0 +1,111 @@ +--- +description: "CodeSandbox сохраняет состояние ядра между вызовами, поэтому переменные и импорты сохраняются. Запускайте Python, JavaScript или Bash так, как это делает агент." +--- + + + +# Интерпретатор кода + +`CodeSandbox` расширяет обычную [песочницу](/sandboxes) за счёт **сохраняющего состояние ядра** — переменные, импорты и определения функций сохраняются между вызовами, как в Jupyter Notebook. Это подходящий инструмент, когда ИИ-агент генерирует и запускает код пошагово. + +Он загружается из шаблона `code-interpreter-v1` (Python 3.14 + Node.js 26, с API выполнения кода на порту 8080) и поддерживает **Python, JavaScript и Bash** из коробки. + + + +## Запуск кода + +```ts +import { CodeSandbox } from '@lizard-build/sdk'; + +// Every sandbox belongs to a project — usage is metered per project +const sandbox = await CodeSandbox.create({ project: 'my-project' }); // defaults to 'code-interpreter-v1' + +await sandbox.runCode('x = 42'); +const result = await sandbox.runCode('print(x * 2)'); +console.log(result.stdout); // "84\n" — x survived from the previous call + +await sandbox.kill(); +``` + +`runCode(code, opts?)` возвращает `Execution`: + +| Поле | Описание | +|---|---| +| `stdout` / `stderr` | Захваченные потоки вывода | +| `results` | Насыщенные результаты (значения, а также сгенерированные изображения / диаграммы) | +| `error` | `ExecutionError` (`name`, `message`, `traceback`), если код выбросил ошибку | +| `executionCount` | Монотонный счётчик для ядра | + + + +## Выбор языка + +По умолчанию — Python. Передайте `language` для разового запуска в другом рантайме: + +```ts +const js = await sandbox.runCode('1 + 1', { language: 'javascript' }); +console.log(js.results[0].data); // "2" + +await sandbox.runCode('echo "$(uname -s)"', { language: 'bash' }); +``` + + + +## Потоковый вывод + +Для долгих ячеек выводите stdout/stderr по мере их генерации, вместо ожидания результата: + +```ts +await sandbox.runCode('for i in range(5): print(i)', { + onStdout: (line) => process.stdout.write(line), + onStderr: (line) => process.stderr.write(line), + onResult: (r) => console.log('result:', r), + onError: (e) => console.error('error:', e.name, e.message), +}); +``` + + + +## Изолированные контексты + +**Контекст** — это независимое пространство имён внутри одной песочницы — используйте один на сессию агента или на пользователя, чтобы их переменные никогда не пересекались. + +```ts +const a = await sandbox.createContext({ language: 'python' }); +const b = await sandbox.createContext({ language: 'python' }); + +await sandbox.runCode('secret = 1', { context: a }); +await sandbox.runCode('print(secret)', { context: b }); // NameError — b never saw it + +await sandbox.listContexts(); +await sandbox.restartContext(a); // clear all variables/state +await sandbox.deleteContext(b); // free its resources +``` + +Передайте **либо** `context` **либо** `language` в `runCode`, не оба сразу — у контекста уже привязан язык. + + + +## Контрольная точка сессии + +Поскольку `CodeSandbox` — это песочница, [пауза и возобновление](/sandboxes/quickstart#pause-and-resume) работают так же. Установите тяжёлый стек зависимостей один раз, поставьте на паузу и возобновите позже с сохранённым состоянием ядра: + +```ts +const sandbox = await CodeSandbox.create({ project: 'my-project' }); +await sandbox.runCode('import subprocess; subprocess.run(["pip", "install", "scikit-learn"])'); +const id = sandbox.sandboxId; +await sandbox.pause(); + +// Later — resume with packages and kernel variables already in place +const resumed = await CodeSandbox.connect(id); +const out = await resumed.runCode('import sklearn; print(sklearn.__version__)'); +console.log(out.stdout); +await resumed.kill(); +``` + + + +## См. также + +- [Справочник SDK](/sandboxes/sdk-reference) — каждый метод `CodeSandbox` и параметр `runCode`. +- [Persistent Volumes](/sandboxes/volumes) — подключите хранилище, которое переживает одну песочницу. diff --git a/_locales/ru/sandboxes/dashboard.mdx b/_locales/ru/sandboxes/dashboard.mdx new file mode 100644 index 0000000..8730ec4 --- /dev/null +++ b/_locales/ru/sandboxes/dashboard.mdx @@ -0,0 +1,63 @@ +--- +description: "Создавайте и изучайте песочницы вручную на странице Sandboxes проекта: API-ключи, живые оболочки, управление жизненным циклом, снимки и тома." +--- + + + +# Панель Sandboxes + +У каждого проекта есть страница **Sandboxes** для создания и изучения песочниц вручную — удобно для отладки среды агента, получения интерактивной оболочки или быстрой проверки того, что произвёл код. Откройте проект и выберите **Sandboxes** в боковой панели (`///sandboxes`). + +На странице три вкладки: **Sandboxes**, **Тома** и **Снимки**. + + + +## Получение API-ключа + +Если вы ещё не пользовались песочницами, пустое состояние проведёт вас через создание **API-ключа** для SDK. Ключ показывается **один раз** — скопируйте его сразу; позже его нельзя получить повторно. Сохраните его как `LIZARD_API_KEY` (см. [Быстрый старт](/sandboxes/quickstart#authenticate)). + + + +## Создание песочницы + +Нажмите **New Песочница** и задайте: + +- **Snapshot** — [шаблон](/sandboxes#templates), из которого загружается песочница (`base` или `code-interpreter-v1`). +- **Location** — регион запуска (по умолчанию — ближайший доступный). +- **Resources** — текущие шаблоны используют 4 vCPU и 4096 MiB RAM; это не настраиваемые при создании параметры размера. + +Песочницы, созданные здесь, не имеют таймаута — они работают, пока вы их не остановите. + + + +## Изучение запущенной песочницы + +Выбор песочницы открывает панель деталей с двумя вкладками. + +**Overview** показывает её ID, шаблон, статус, регион и CPU/память, а также: + +- **Exposed ports** — каждый порт, открытый с помощью [`getHost`](/sandboxes/quickstart#exposing-a-port), с копируемым публичным URL `https://…onlizard.com`, который можно открыть напрямую. +- **SSH access** — когда доступно, готовая к вставке команда `ssh root@ -p ` и сгенерированный пароль. + +**Terminal** даёт браузерную оболочку прямо в микро-VM (через SSH), чтобы можно было изучать среду, не покидая дашборд. + +Запущенные песочницы сообщают об использовании CPU и памяти в реальном времени в списке; приостановленные и остановленные показывают нули. + + + +## Жизненный цикл + +- **Kill Песочница** (в панели деталей) немедленно завершает песочницу и освобождает её ресурсы — включая отсоединение любого [тома](/sandboxes/volumes). +- **Pause / resume** управляются из [SDK](/sandboxes/quickstart#pause-and-resume); приостановленная песочница отображается как **Paused** и не потребляет вычислительных ресурсов по запросу. + + + +## Снимки + +Вкладка **Снимки** перечисляет шаблоны, из которых может загрузиться песочница — встроенные `base` и `code-interpreter-v1`. Команда загрузки пользовательского шаблона не входит в текущий публичный CLI. Каждая запись показывает её vCPU/память по умолчанию и описание. + + + +## Тома + +Вкладка **Тома** управляет [постоянным хранилищем](/sandboxes/volumes): создайте том с именем и размером и посмотрите, к какой песочнице каждый из них подключён. diff --git a/_locales/ru/sandboxes/index.mdx b/_locales/ru/sandboxes/index.mdx new file mode 100644 index 0000000..5f7a34a --- /dev/null +++ b/_locales/ru/sandboxes/index.mdx @@ -0,0 +1,90 @@ +--- +description: "Песочница — это изолированный микро-VM Firecracker, который загружается за миллисекунды, выполняет код и удаляется. Вычислительная основа для ИИ-агентов." +--- + + + +# Песочницы + +**Песочница** — это изолированный микро-VM Firecracker, который вы запускаете по требованию, выполняете внутри код и удаляете по завершении. Каждая песочница — полноценная Linux-среда со своей файловой системой, сетью и пространством процессов — загружается за миллисекунды, а не минуты. + +Песочницы — вычислительная основа для ИИ-агентов, интерпретаторов кода, оценок и задач в стиле CI на Lizard. Если [сервис](/concepts/architecture) — это долгоживущее развертывание, привязанное к репозиторию, то песочница — **эфемерная, программная и одноразовая** — создавайте песочницу для каждой задачи в пределах емкости вашего аккаунта. + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const { stdout } = await sandbox.process.exec('echo "hello from Lizard"'); +console.log(stdout); // hello from Lizard +await sandbox.kill(); +``` + + + +## Когда использовать песочницу + +| Используйте **песочницу**, когда… | Используйте **сервис**, когда… | +|---|---| +| Агенту нужно выполнить недоверенный или сгенерированный код | Вы развертываете приложение, которое должно работать постоянно | +| Нужен чистый, одноразовый Linux за каждой задачей | Нужен стабильный URL `..onlizard.com` и TLS | +| Нужно распараллелить множество изолированных задач | У вас есть один всегда работающий процесс | +| Нагрузка кратковременная или приостанавливается | Нагрузка привязана к git и автоматически переразвертывается | + +После того как агент создал работающее приложение внутри песочницы, вы можете продвинуть его в постоянный сервис с помощью [`lizard up`](/deploy/upload) — без Dockerfile. + + + +## Почему они быстрые + +- **Микровычислители Firecracker** — отдельный Linux-гость для каждой песочницы. У рантаймов приложений разные правила изоляции. Аппаратная виртуализация отделяет гостя от хоста. Контролируйте учетные данные и сетевой доступ для кода, которому не доверяете. +- **Приостановка и возобновление** — приостановка замораживает vCPU микро-VM. Память, файловая система и запущенные процессы сохраняются как есть, поэтому возобновление продолжает ровно с того же места — без переустановки пакетов или повторного прогрева кэшей. Именно это позволяет долгим сессиям агентов выживать при отдельных вызовах. Состояние хранится в памяти хоста, а не на диске, поэтому не выживает при сбое хоста. См. [приостановка и возобновление](/sandboxes/quickstart#pause-and-resume). +- **Загрузка из шаблона** — каждый узел заранее создает эталонный снимок для каждого шаблона, поэтому `create` — это восстановление, а не холодная загрузка. + + + +## Шаблоны + +Песочница загружается из **шаблона** (в панели управления он также называется *снимком*). Доступны два встроенных шаблона: + +| Шаблон | Содержимое | Подходит для | +|---|---|---| +| `base` | Debian Linux, Node.js 26 и Lizard CLI | Командные оболочки общего назначения и среды сборки | +| `code-interpreter-v1` | Python 3.14 + Node.js 26, с HTTP API выполнения кода на порту 8080 | ИИ-интерпретаторы кода — управляйте через [`CodeSandbox`](/sandboxes/code-interpreter) | + +`base` — по умолчанию. Публичный API создания принимает эти два имени шаблона. Загрузка пользовательских шаблонов через этот API не предусмотрена. + + + +## Жизненный цикл + +Песочница переходит между тремя состояниями: + +``` +create ──▶ running ⇄ paused ──▶ stopped + (killed or expired) +``` + +- **running** — гость может выполнять команды, работать с файлами и обслуживать открытые порты. +- **paused** — vCPU остановлены. Память гостя и состояние процессов остаются на хосте; это не устойчивый снимок или резервная копия. +- **stopped** — песочница завершена через удаление или истечение срока. Её локальная файловая система больше недоступна. + +SDK по умолчанию отправляет время жизни 5 минут. При прямом вызове API создания можно передать `timeoutMs: 0`, чтобы отключить ограничение срока действия. Передавайте явный таймаут, когда скрипт должен вести себя одинаково на всех клиентах, и освобождайте песочницу по завершении задачи. Команды не сбрасывают время жизни. + +Приостановка предназначена для сохранения оставшегося времени работы. Проверьте [текущую проблему жизненного цикла](/platform/known-issues#sandbox-pause-and-expiration) перед тем, как полагаться на приостановку дольше исходного срока. Для хранения постоянных файлов используйте [том](/sandboxes/volumes); приостановленный гость не выживает при сбое хоста. + + + +## Ресурсы и лимиты + +Каждая песочница работает на фиксированных **4 vCPU / 4096 MiB RAM**. Публичный API создания не имеет настройки размера для каждой песочницы. Каждая песочница наследует ресурсы своего шаблона. + +Регион выбирается автоматически с учётом доступных ресурсов; в панели управления можно указать нужный регион. Для квот приложений и доступных ресурсов песочниц могут действовать разные правила. См. [лимиты](/platform/limits). + + + +## Способы управления песочницами + +| Способ управления | Подходит для | Начните здесь | +|---|---|---| +| **SDK** (JS / Python) | Агенты, приложения и скрипты — включая с сохранением состояния, многоязычное выполнение через [`CodeSandbox`](/sandboxes/code-interpreter) | [Быстрый старт](/sandboxes/quickstart) · [Справочник SDK](/sandboxes/sdk-reference) | +| **Панель управления** | Ручное создание, терминал, SSH, мониторинг | [Панель управления](/sandboxes/dashboard) | \ No newline at end of file diff --git a/_locales/ru/sandboxes/quickstart.mdx b/_locales/ru/sandboxes/quickstart.mdx new file mode 100644 index 0000000..f0bfd31 --- /dev/null +++ b/_locales/ru/sandboxes/quickstart.mdx @@ -0,0 +1,237 @@ +--- +description: "Запустите свою первую песочницу с Lizard SDK: установка, создание API-ключа, выбор проекта, запуск кода, работа с файлами, проброс порта и пауза." +--- + + + +# Быстрый старт с песочницами + +Запустите песочницу, выполните код в ней, пробросьте порт и поставьте на паузу с помощью Lizard SDK. + + + +## Установка + +```bash +# JavaScript / TypeScript +npm install @lizard-build/sdk + +# Python +pip install lizard-sdk +``` + + + +## Аутентификация + +Песочницы аутентифицируются с помощью **API-ключа**. Создайте его в дашборде (**Sandboxes → Get started → New API key**) — он показывается один раз, поэтому сразу скопируйте его. + +Задайте его в окружении, и SDK подхватит его автоматически: + +```bash +export LIZARD_API_KEY="" +``` + +Можете также передать его явно: `Sandbox.create('base', { apiKey, project })`. + + + +## Выбор проекта + +Каждая песочница принадлежит проекту — расход учитывается по проектам, поэтому API отклонит создание без проекта. Укажите проект по его ID, слагу или имени. + +Клиент `Lizard` закрепляет один проект, поэтому нужно указать его только раз: + +```ts +import { Lizard } from '@lizard-build/sdk'; + +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +from lizard import Lizard + +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +`Sandbox.create` принимает тот же параметр `project`, когда не хотите держать клиент. Обе формы используются ниже. + + + +## Ваша первая песочница + +**JavaScript / TypeScript** + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +// Boot from a template (default: 'base') in a project +const sandbox = await Sandbox.create('base', { project: 'my-project' }); + +// Run a command and wait for it to finish +try { + const result = await sandbox.process.exec('node -e "console.log(2 ** 10)"'); + console.log(result.stdout); // 1024 + console.log(result.exitCode); // 0 +} finally { + await sandbox.kill(); +} +``` + +**Python** + +```python +from lizard import Sandbox + +sandbox = Sandbox.create("base", project="my-project") + +# exec_ (trailing underscore) because `exec` is reserved in Python +try: + result = sandbox.process.exec_("python -c 'print(2 ** 10)'") + print(result.stdout) # 1024 +finally: + sandbox.kill() +``` + +`process.exec` возвращает `{ stdout, stderr, exitCode }`. Он ждёт завершения команды — фоновые долгие процессы запускайте с завершающим `&`. + + + +## Работа с файлами + +`sandbox.fs` читает и пишет прямо в файловую систему микро-VM, создавая родительские директории при необходимости. + +```ts +await sandbox.fs.write('/app/server.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('hello from Lizard')).listen(3000); +`); + +const src = await sandbox.fs.read('/app/server.js'); +const entries = await sandbox.fs.list('/app'); // [{ name, path, type, size }] +await sandbox.fs.makeDir('/app/data'); +await sandbox.fs.remove('/app/old.log'); +``` + +| Метод | Описание | +|---|---| +| `fs.write(path, data)` | Записать файл — строка или байты; создаёт родительские директории | +| `fs.read(path)` | Прочитать файл как строку UTF-8 | +| `fs.list(path)` | Вывести содержимое директории | +| `fs.makeDir(path)` | Создать директорию и недостающие родители | +| `fs.remove(path)` | Удалить файл или директорию | + + + +## Проброс порта + +Запустите HTTP-сервер внутри песочницы и получите публичный HTTPS-URL для него — без туннелей. + +```ts +await sandbox.process.exec('node /app/server.js &'); // listen on :3000 + +const host = await sandbox.getHost(3000); +console.log(`Live at https://${host}`); +// https://-3000.sandbox..onlizard.com +``` + +`getHost(port)` регистрирует маршрут к этому порту и возвращает хостнейм. URL публичный и с TLS-терминацией. Удалить его можно снова в дашборде. + + + +## Пауза и возобновление + +Пауза заморозит гостевые vCPU и сохранит текущее состояние в памяти хоста. Она не создаёт устойчивый снапшот. Проверьте [проблему с паузой и истечением срока](/platform/known-issues#sandbox-pause-and-expiration) перед удержанием сессии дольше первоначального дедлайна. + +```ts +// Set the environment up once +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +await sandbox.process.exec('npm install -g some-heavy-toolchain'); +const id = sandbox.sandboxId; + +await sandbox.pause(); // freeze the guest; see the lifecycle issue below + +// …minutes or hours later, from anywhere: +const resumed = await Sandbox.connect(id); // resumes guest state still held by the host +await resumed.process.exec('some-heavy-toolchain --version'); // already installed +await resumed.kill(); +``` + +`Sandbox.connect(id)` автоматически возобновляет поставленную на паузу песочницу. Можно также вызвать `sandbox.resume()` на уже имеющемся хендле. + +**Python** + +```python +sandbox = Sandbox.create("base", project="my-project") +sandbox.process.exec_("pip install numpy pandas") +sandbox_id = sandbox.sandbox_id +sandbox.pause() + +resumed = Sandbox.connect(sandbox_id) # resumes guest state still held by the host +resumed.process.exec_("python -c 'import numpy'") +resumed.kill() +``` + + + +## Таймауты + +Песочница с положительным таймаутом истекает после этого времени жизни. По умолчанию SDK ставит пять минут; `timeoutMs: 0` при создании отключает истечение. Задайте явный лимит и освободите песочницу по завершении задачи. Измените работающую песочницу так: + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); // 10 min +await sandbox.setTimeout(30 * 60 * 1000); // extend to 30 min from now +``` + +Пауза предназначена для заморозки оставшегося времени работы, но текущая [проблема жизненного цикла](/platform/known-issues#sandbox-pause-and-expiration) требует подтверждённого релиза бэкенда. Не полагайтесь на неограниченную паузу для сохранения данных. + + + +## Управление песочницами + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project' }); +const info = await sandbox.getInfo(); // { sandboxId, template, startedAt, endAt, … } + +const all = await Sandbox.list(); // every running sandbox for this account +await sandbox.kill(); +``` + + + +## Полный пример + +Агент, который пишет скрипт, запускает его, отдаёт результат и ставит гостя на паузу для последующего вызова: + +```ts +import { Sandbox } from '@lizard-build/sdk'; + +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 15 * 60 * 1000 }); + +try { + await sandbox.fs.write('/app/app.js', ` + const http = require('http'); + http.createServer((_, res) => res.end('ok')).listen(3000); + `); + await sandbox.process.exec('node /app/app.js &'); + + const host = await sandbox.getHost(3000); + const res = await fetch(`https://${host}`); + console.log(await res.text()); // ok + + await sandbox.pause(); // resume later with Sandbox.connect(sandbox.sandboxId) +} catch (err) { + await sandbox.kill(); + throw err; +} +``` + + + +## Дальнейшие шаги + +- **[Справочник SDK](/sandboxes/sdk-reference)** — каждый метод `Sandbox`, `CodeSandbox` и `Volume`. +- **[Интерпретатор кода](/sandboxes/code-interpreter)** — запуск стейтфулного мультиязыкового кода. +- **[Persistent Volumes](/sandboxes/volumes)** — подключение хранилища, которое переживает отдельную песочницу. diff --git a/_locales/ru/sandboxes/sdk-reference.mdx b/_locales/ru/sandboxes/sdk-reference.mdx new file mode 100644 index 0000000..7456dbf --- /dev/null +++ b/_locales/ru/sandboxes/sdk-reference.mdx @@ -0,0 +1,144 @@ +--- +description: "Все классы и методы Lizard SDK для JavaScript и Python: Lizard, Песочница, CodeSandbox и Том с параметрами и типами возвращаемых значений." +--- + + + +# Справочник SDK + +Пакеты `@lizard-build/sdk` (JS/TS) и `lizard-sdk` (Python) — это то, чем пользуются большинство агентов, приложений и скриптов для управления песочницами. На этой странице перечислены все классы и методы; пошаговое руководство см. в [Quickstart](/sandboxes/quickstart). + + + +## Установка и аутентификация + +```bash +npm install @lizard-build/sdk # JavaScript / TypeScript +pip install lizard-sdk # Python +``` + +SDK считывает `LIZARD_API_KEY` из окружения или принимает явный параметр `apiKey` в `Sandbox.create` / `Sandbox.connect`. Как создать ключ — в [Quickstart → Аутентификация](/sandboxes/quickstart#authenticate). + +Каждая песочница также принадлежит **проекту** — расход учитывается по проекту, поэтому попытка создания без проекта будет отклонена. + +## `Lizard` + +Клиент, привязанный к одному проекту, чтобы указывать проект один раз, а не при каждом вызове. + +| Метод | Описание | +|---|---| +| `new Lizard({ project, apiKey?, apiUrl?, timeoutMs? })` | Создать клиент. `project` обязателен — его ID, slug или имя (`Lizard(project=…)` в Python). | +| `lizard.create(template?, options?)` | Запустить песочницу в проекте клиента. | +| `lizard.connect(sandboxId)` | Подключиться к песочнице по ID, автоматически возобновив её, если была приостановлена. | +| `lizard.list()` | Получить список всех запущенных песочниц аккаунта. | +| `lizard.projectId()` | Разрешить ссылку на проект клиента в его ID (кэшируется после первого вызова). | + +```ts +const lizard = new Lizard({ project: 'my-project' }); +const sandbox = await lizard.create('base'); +``` + +```python +lizard = Lizard(project="my-project") +sandbox = lizard.create("base") +``` + +Ссылка на проект, не соответствующая ни одному из доступных ключу, вызовет ошибку до запуска песочницы, перечислив доступные проекты. + +> В Python имена методов с подчёркиванием на конце (`exec_`) избегают перекрытия с зарезервированными словами, а свойства — в snake_case (`sandbox_id`) вместо camelCase (`sandboxId`). В примерах ниже используются имена JS/TS; точные сигнатуры смотрите в установленном Python-пакете. + +## `Sandbox` + +| Метод | Описание | +|---|---| +| `Sandbox.create(template?, options?)` | Запустить песочницу. `template` по умолчанию `'base'`; `options.project` задаёт проект для биллинга. | +| `Sandbox.connect(sandboxId)` | Подключиться к песочнице по ID, автоматически возобновив её, если была приостановлена. | +| `Sandbox.list()` | Получить список всех запущенных песочниц аккаунта. | +| `sandbox.sandboxId` | ID песочницы (`sandbox_id` в Python). | +| `sandbox.process.exec(cmd)` | Выполнить команду и дождаться завершения (`process.exec_` в Python). Возвращает `{ stdout, stderr, exitCode }`. | +| `sandbox.fs.write(path, data)` | Записать файл — строка или байты; создаёт родительские директории. | +| `sandbox.fs.read(path)` | Прочитать файл как UTF-8 строку. | +| `sandbox.fs.list(path)` | Список элементов директории → `[{ name, path, type, size }]`. | +| `sandbox.fs.makeDir(path)` | Создать директорию и все недостающие родители. | +| `sandbox.fs.remove(path)` | Удалить файл или директорию. | +| `sandbox.getHost(port)` | Зарегистрировать маршрут к `port` и вернуть публичный TLS-хост. | +| `sandbox.pause()` | Остановить гостевые vCPU и сохранить состояние в памяти хоста. Подробнее в [статусах жизненного цикла](#lifecycle-status) перед тем как полагаться на паузу после исходного дедлайна. | +| `sandbox.resume()` | Возобновить приостановленную песочницу на месте. | +| `sandbox.setTimeout(ms)` | Задать оставшееся время жизни запущенной песочницы в миллисекундах (минимум 1000). | +| `sandbox.getInfo()` | Получить метаданные → `{ sandboxId, template, startedAt, endAt, … }`. | +| `sandbox.kill()` | Немедленно завершить песочницу и освободить ресурсы. | + +### `Sandbox.create(template?, options?)` + +| Параметр | Тип | По умолчанию | Примечания | +|---|---|---|---| +| `template` | string | `'base'` | `'base'` или `'code-interpreter-v1'` — две поддерживаемые [шаблоны](/sandboxes#templates) | +| `project` | string | — | **Обязательно.** Проект для биллинга — его ID, slug или имя (`project` в Python). Не требуется при использовании клиента `Lizard`. | +| `projectId` | string | — | Точный ID проекта; пропускает разрешение `project` | +| `timeoutMs` | int | дефолт SDK 5 мин | Время жизни в мс | +| `region` | string | auto | Закрепить за регионом | +| `volumeId` | string | — | Подключить [том](/sandboxes/volumes) в `/data` | +| `apiKey` | string | переменная `LIZARD_API_KEY` | Явный API-ключ, переопределяет окружение | + +```ts +const sandbox = await Sandbox.create('base', { project: 'my-project', timeoutMs: 10 * 60 * 1000 }); +``` + +## `CodeSandbox` + +Расширяет `Sandbox` стейтфул-ядром. Полное руководство в [Интерпретатор кода](/sandboxes/code-interpreter). + +| Метод | Описание | +|---|---| +| `CodeSandbox.create(options?)` | Запустить интерпретатор кода (по умолчанию шаблон `code-interpreter-v1`). Принимает те же `project`, что и `Sandbox.create`. | +| `CodeSandbox.connect(sandboxId)` | Подключиться к (и автоматически возобновить) существующую песочницу интерпретатора. | +| `sandbox.runCode(code, opts?)` | Выполнить код в ядре. Возвращает `Execution`. | +| `sandbox.createContext(opts)` | Создать изолированное пространство имён — `{ language }`. | +| `sandbox.listContexts()` | Получить список контекстов песочницы. | +| `sandbox.restartContext(context)` | Очистить все переменные/состояние в контексте. | +| `sandbox.deleteContext(context)` | Освободить ресурсы контекста. | + +### `runCode(code, opts?)` + +| Параметр | Описание | +|---|---| +| `language` | Среда выполнения для разового вызова — `'python'` (по умолчанию), `'javascript'` или `'bash'`. Взаимоисключающ с `context`. | +| `context` | Выполнить внутри конкретного изолированного контекста вместо дефолтного. Взаимоисключающ с `language`. | +| `onStdout` / `onStderr` | Потоковый вывод построчно по мере генерации. | +| `onResult` | Вызывается для каждого насыщенного результата (значения, сгенерированные изображения/диаграммы). | +| `onError` | Вызывается с `ExecutionError`, если код выбросил ошибку. | + +Возвращает `Execution`: + +| Поле | Описание | +|---|---| +| `stdout` / `stderr` | Захваченные потоки вывода | +| `results` | Насыщенные результаты (значения и любые сгенерированные изображения/диаграммы) | +| `error` | `ExecutionError` (`name`, `message`, `traceback`), если код выбросил ошибку | +| `executionCount` | Монотонный счётчик ядра | + +## `Volume` + +Подробнее в [Persistent Volumes](/sandboxes/volumes). + +| Метод | Описание | +|---|---| +| `Volume.create(projectId, name, options)` | Создать том. `options.sizeGb` по умолчанию `5`. | +| `Volume.list(projectId)` | Список томов в проекте → `[{ id, name, sizeGb, status, attachedTo, … }]`. | +| `Volume.get(projectId, volumeId)` | Получить хендл существующего тома. | +| `volume.getInfo(projectId)` | Получить метаданные и статус подключения. | +| `volume.delete(projectId)` | Удалить том — он должен быть сначала отключён. | + + + +## См. также + +- [Quickstart](/sandboxes/quickstart) — установка, аутентификация и полное руководство. +- [Интерпретатор кода](/sandboxes/code-interpreter) — руководство по `CodeSandbox`. +- [Persistent Volumes](/sandboxes/volumes) — руководство по `Volume`. + + + +## Статусы жизненного цикла + +Перед тем как полагаться на паузу для сохранения сессии после исходного дедлайна, прочитайте [известные проблемы](/platform/known-issues#sandbox-pause-and-expiration). Пауза держит состояние гостя в памяти хоста; это не долговечный бэкап. diff --git a/_locales/ru/sandboxes/volumes.mdx b/_locales/ru/sandboxes/volumes.mdx new file mode 100644 index 0000000..cd4f97b --- /dev/null +++ b/_locales/ru/sandboxes/volumes.mdx @@ -0,0 +1,79 @@ +--- +description: "Подключите том к /data, чтобы сохранять чекпоинты, веса или рабочую директорию между перезапусками песочниц. Создавайте, подключайте и управляйте томами." +--- + +# Persistent Volumes + +Песочницы эфемерны — когда песочница убивается или истекает срок её действия, её файловая система исчезает. **Том** — это постоянное блочное хранилище, которое переживает любую отдельную песочницу. Подключите его, чтобы сохранять данные (чекпоинты, веса моделей, рабочую директорию) между перезапусками песочниц. + +Том подключается к **одной песочнице за раз** и монтируется в **`/data`** внутри микро-VM. Поскольку том привязан к узлу, на котором он находится, песочница, подключающая его, планируется на том же узле. + + + +## Создание и подключение + +Подключите том, передав его ID в `Sandbox.create` наряду с проектом, на который списывается песочница. Всё, что записано в `/data`, сохраняется после удаления песочницы. + +```ts +import { Sandbox, Volume } from '@lizard-build/sdk'; + +// Create a 10 GB volume in a project (default size: 5 GB) +const volume = await Volume.create('proj_123', 'agent-workdir', { sizeGb: 10 }); + +// Attach it to a sandbox — mounted at /data +const sandbox = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + await sandbox.fs.write('/data/state.json', JSON.stringify({ step: 1 })); +} finally { + await sandbox.kill(); // the volume persists +} + +// A later sandbox re-attaches and sees the data +const next = await Sandbox.create('base', { project: 'proj_123', volumeId: volume.volumeId }); +try { + console.log(await next.fs.read('/data/state.json')); // {"step":1} +} finally { + await next.kill(); +} +``` + + + +## Управление томами + +```ts +await Volume.list('proj_123'); // [{ id, name, sizeGb, status, attachedTo, … }] +const v = await Volume.get('proj_123', 'vol_abc'); +await v.getInfo('proj_123'); +await v.delete('proj_123'); // must be detached first +``` + +| Метод | Описание | +|---|---| +| `Volume.create(projectId, name, { sizeGb })` | Создать том (по умолчанию 5 ГБ) | +| `Volume.list(projectId)` | Получить список томов в проекте | +| `Volume.get(projectId, volumeId)` | Получить дескриптор существующего тома | +| `volume.getInfo(projectId)` | Получить метаданные и статус подключения | +| `volume.delete(projectId)` | Удалить том (должен быть отключен) | + + + +## В дашборде + +Тома находятся на вкладке **Sandboxes → Тома** проекта. Создайте том, задав имя и размер; таблица показывает размер каждого тома, статус (`available` / `attached`) и какая песочница его держит. Том автоматически возвращается в `available`, когда его песочница убивается или истекает. См. руководство по [Панель управления](/sandboxes/dashboard). + + + +## Примечания + +- Том может быть подключен только к **одной песочнице** за раз. Попытка подключить уже подключённый том вернёт конфликт. +- Удаление песочницы (или истечение её срока) **отключает** том — не удаляет его. Данные сохраняются для следующего подключения. +- Удалите сам том, чтобы освободить хранилище. +- Приостановленная песочница всё равно удерживает подключение. Persistent Volumes используют локальное хранилище узла; экспортируйте данные, которые нужны для восстановления после сбоя узла. См. [хранилище и восстановление](/platform/storage-and-recovery). + + + +## См. также + +- [SDK Reference](/sandboxes/sdk-reference) — каждый метод `Volume`. +- [Quickstart](/sandboxes/quickstart) — подключение тома при создании песочницы. diff --git a/_locales/ru/studio/_meta.ts b/_locales/ru/studio/_meta.ts new file mode 100644 index 0000000..39129ce --- /dev/null +++ b/_locales/ru/studio/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'getting-started': "Установить Lizard Studio", +}; diff --git a/_locales/ru/studio/getting-started.mdx b/_locales/ru/studio/getting-started.mdx new file mode 100644 index 0000000..8c1adce --- /dev/null +++ b/_locales/ru/studio/getting-started.mdx @@ -0,0 +1,145 @@ +--- +title: "Установка Lizard Studio для Claude Code и ChatGPT" +description: "Установите Lizard Studio в Chrome, подключите Claude Code или ChatGPT к локальному проекту и сделайте первое редактирование сайта. Следуйте руководству по настройке." +--- + + + +# Установка Lizard Studio + +Lizard Studio — бесплатное расширение для Chrome, которое подключает Claude Code или ChatGPT к странице, которую вы создаёте. Откройте чат рядом со страницей, выберите элемент и попросите агента отредактировать файлы в вашем локальном проекте. Расширение включает инспекцию страницы, аннотации, линейки, пипетку и инструменты отладки браузера. + +Это руководство проведёт вас от установки до одного редактирования исходного кода, которое сохранится после обновления страницы. Для примера, который можно скачать, см. [руководство по визуальному редактированию в Claude Code](https://lizard.build/blog/claude-code-visual-editor). + + + +## Что понадобится + +- Google Chrome на macOS, Windows или Linux. +- Node.js и npm. Локальный хост требует Node.js 18 или новее; выбранный вами агент может иметь более высокие требования. Используйте версию Node.js, которую поддерживают оба. +- Локальный CLI для Claude Code или ChatGPT, выполненный вход под вашей учётной записью. +- Папка локального проекта. Чтобы увидеть правки исходного кода в браузере, запустите сервер разработки этого проекта и откройте его URL. + +Расширение и хост бесплатны и распространяются под лицензией MIT. Использование модели подчиняется требованиям, лимитам и тарифам вашего провайдера. Учётная запись Lizard для использования Lizard Studio не требуется. + + + +## 1. Добавьте расширение для Chrome + +Откройте [Lizard Studio в Chrome Web Store](https://chromewebstore.google.com/detail/kgbaeoalmkabpoglpjcdmppdmcipfdeh) и нажмите **Установить в Chrome**. Закрепите расширение, если хотите иметь доступ к нему из панели инструментов. + +Панель инструментов предоставляет инструменты дизайна; боковая панель Chrome содержит ваши чаты. Установка из магазина не требует режима разработчика. + + + +## 2. Установите ваш агент + +Выберите агент, которым хотите пользоваться. Другой можно добавить позже. + +Для Claude Code следуйте [официальному руководству по установке](https://code.claude.com/docs/en/setup). Проверьте установку в терминале: + +```bash +claude --version +``` + +Для ChatGPT в Lizard Studio установите Codex CLI: + +```bash +npm install -g @openai/codex +codex --version +``` + +В интерфейсе Lizard Studio этот агент называется **ChatGPT**. Пакет и терминальная команда используют название **Codex**. Это локальный агент программирования, подключённый к вашему проекту; он не встраивает веб-сайт chatgpt.com. + +Откройте выбранный агент и завершите процесс входа перед тем, как продолжить. Поддерживаемые пути подключения описаны в [README Lizard Studio](https://github.com/lizard-build/lizard-studio#setup). + + + +## 3. Установите локальный хост + +Выполните эту команду один раз в терминале: + +```bash +npx @lizard-build/lizard-studio-host install +``` + +Хост связывает расширение Chrome с агентом на вашем компьютере. Установщик копирует хост в `~/.lizard-studio/host` и регистрирует его в браузере. Держите Node.js установленным: браузер использует его для запуска хоста. + +Повторно откройте боковую панель расширения после установки. Если вы обновили существующий хост, откройте панель снова перед запуском нового чата. + + + +## 4. Подключите страницу к её проекту + +Запустите сервер разработки проекта обычной командой. Откройте выводимый им URL в Chrome, затем откройте Lizard Studio на этой вкладке. + +Начните чат, выберите **Claude Code** или **ChatGPT** и укажите папку, содержащую исходный код этого проекта. Каждый чат хранит свою папку проекта и разрешения. Вкладка с правильной страницей сама по себе не сообщает агенту, какой локальный репозиторий нужно менять. + +Перед запросом правки проверьте связь запросом только на чтение: + +```text +Read this page's title and inspect its main heading. Tell me which +local project folder you are using. Do not change any files yet. +``` + +Если агент указывает не ту папку, исправьте выбор перед продолжением. + + + +## 5. Выберите элемент и сделайте одно редактирование + +Выберите **Селектор** на панели инструментов страницы и кликните по элементу, который хотите изменить. Выбор добавляет контекст в чат. Для визуальной проблемы, затрагивающей несколько элементов, используйте **Аннотация**, чтобы отметить область и добавить скриншот в чат. + +Попробуйте запрос с измеримым результатом: + +```text +Find the source for the selected card's action row. Set the gap +between its buttons to 24px in the project files. Keep the button +labels and colors unchanged. Show the diff, then inspect the +rendered row to check its computed gap. +``` + +Изучите предложенные изменения файлов и используйте управление разрешениями, чтобы одобрить нужную работу. Ваш режим разрешений определяет, какие действия требуют отдельного подтверждения. + +Когда сервер разработки перезагрузит страницу, проверьте результат. Если перезагрузки не происходит автоматически, обновите Chrome. + + + +## 6. Проверьте, что правка сохраняется + +Временное изменение DOM может выглядеть верно до обновления. Правка исходного кода меняет файлы, которые обслуживает ваш сервер разработки. + +Посмотрите дифф файлов в редакторе или выполните `git diff` из папки проекта. Обновите страницу и снова проверьте тот же элемент. Для приведённого выше примера вычисленный gap всё ещё должен быть `24px`. Проверьте и настольную, и узкую вёрстку перед тем, как оставить изменение. + +Редактирование локального проекта не обновляет развёрнутый сайт. Разверните отдельно, когда захотите вывести изменения в продакшн. + + + +## Если соединение не работает + +| Что вы видите | Что проверить | +|---|---| +| Боковая панель не может связаться с хостом | Запустите установщик хоста, убедитесь, что Node.js доступен, затем снова откройте панель. | +| Агент не может запуститься | Проверьте `claude --version` или `codex --version` в терминале и завершите вход в этот агент. | +| Агент видит страницу, но не находит её код | Выберите правильную локальную папку и убедитесь, что вкладка использует сервер разработки этого проекта. | +| Правка пропадает при обновлении | Проверьте дифф. Попросите внести изменение в исходный код, если агент поменял только живой DOM. | +| Панель инструментов не появляется на странице настроек Chrome | Chrome блокирует контент-скрипты на страницах `chrome://`, на странице новой вкладке и в Chrome Web Store. Откройте обычный веб-сайт. | + +На macOS размещение хоста в `~/.lizard-studio/host` также обходит ограничения, с которыми Chrome может столкнуться при запуске хоста из Desktop, Documents или Downloads. Подробнее см. в [примечаниях к хосту в README](https://github.com/lizard-build/lizard-studio#2-the-local-host-one-time). + + + +## Куда отправляются ваши данные + +Расширение и хост работают на вашем компьютере. Выбранный провайдер модели получает запросы, которые вы отправляете через его агент. Lizard Studio не использует чат-сервер Lizard и не собирает телеметрию. Локальная установка не означает, что облачная модель обрабатывает ваши промпты локально. Прочитайте [политику конфиденциальности Lizard Studio](https://github.com/lizard-build/lizard-studio/blob/main/PRIVACY.md) перед использованием с проектом, имеющим ограничения по данным. + + + +## Связанные руководства + +- [Выберите элемент и исправьте его CSS](https://lizard.build/blog/claude-code-visual-editor) +- [Используйте ChatGPT для редактирования локального сайта](https://lizard.build/studio/chatgpt) +- [Сравните Lizard Studio и Claude в Chrome](https://lizard.build/studio/compare/claude-in-chrome) +- [Выберите GUI для Claude Code](https://lizard.build/blog/claude-code-gui) + +Настройка проверена на исходном коде Lizard Studio 14 сентября 2026 года. diff --git a/_locales/ru/variables/_meta.ts b/_locales/ru/variables/_meta.ts new file mode 100644 index 0000000..54358a7 --- /dev/null +++ b/_locales/ru/variables/_meta.ts @@ -0,0 +1,5 @@ +export default { + index: "Переменные и секреты", + references: "Перекрёстные ссылки между сервисами", + troubleshooting: "Устранение неполадок", +}; diff --git a/_locales/ru/variables/index.mdx b/_locales/ru/variables/index.mdx new file mode 100644 index 0000000..3e17d03 --- /dev/null +++ b/_locales/ru/variables/index.mdx @@ -0,0 +1,112 @@ +--- +description: "Настройте секреты на уровне сервиса или проекта, узнайте порядок их слияния и какие значения попадают в сборку, а какие в запущенный контейнер." +--- + + + +# Переменные и секреты + +Lizard хранит конфигурацию как **секреты**. У них есть два уровня видимости — **сервис** (по умолчанию) и **проект** (`--global`) — и они объединяются в окружение приложения в строго заданном порядке приоритета. Глобального уровня рабочего пространства нет. + + + +## Установка переменных + +`lizard secrets set` принимает переменное число аргументов — можно задать один или несколько секретов сразу. По умолчанию он пишет в **привязанный сервис**: + +```bash +lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info +lizard secrets set API_KEY=sk_live_… --service api +``` + +Добавьте `--global`, чтобы записать в **область проекта** (увидит каждый сервис в проекте): + +```bash +lizard secrets set NODE_ENV=production --global +``` + + + +## Просмотр, удаление, импорт + +```bash +lizard secrets list # current scope +lizard secrets list --show # reveal values +lizard secrets delete OLD_KEY ANOTHER_KEY # variadic +cat .env | lizard secrets import # import dotenv from stdin +``` + +Все флаги описаны в [справке по команде `lizard secrets`](/cli/secrets). + + + +## Область видимости + +| Уровень | Команда | Хранится как | Видимость для | +|---------|---------|--------------|-----------| +| **Сервис** (по умолчанию) | `lizard secrets set K=v --service ` | `secrets.services[]` | только этот сервис | +| **Проект** (глобальный) | `lizard secrets set K=v --global` | `secrets.shared` | все сервисы в проекте | + +**По умолчанию — уровень сервиса.** Скомпрометированный сервис может прочитать своё окружение — более широкая область видимости означает больше учётных данных без нужды. Используйте `--global` только для несекретных, заведомо публичных значений вроде `LOG_LEVEL`, `NODE_ENV`, флагов функций или публичного URL фронтенда `SENTRY_DSN`. Если не уверены, является ли значение секретом — считайте его секретом и ограничьте сервисом. + +Для общих ресурсов вроде базы данных **не кладите** DSN в `--global` — привяжите его к каждому потребителю через [ссылку](/variables/references): + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service worker +``` + +Ротация происходит один раз в аддоне; все ссылки обновятся автоматически. + + + +## Приоритет + +Когда один ключ задан в нескольких местах, **побеждает последний записавший**: + +``` +addon-issued env < project secrets < project env < app env < app secrets < platform vars +``` + +Поэтому **секреты приложения перекрывают секреты проекта**, а **платформенные переменные** (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) применяются в самом конце и их нельзя переопределить. + + + +## Время сборки и время выполнения + +Большинство изменений переменных вступают в силу **без пересборки** — сервис перезапускается и подхватывает их за несколько секунд. Исключения — значения времени сборки, зашиваемые в образ: + +- Изменения `VITE_*` и `NEXT_PUBLIC_*` **требуют пересборку** при следующем деплое. + +См. [Пайплайн сборки → триггеры пересборки](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## Проверка + +Убедитесь, что запущенный сервис видит именно то, что вы ждёте: + +```bash +lizard ssh --service api -- env +``` + +Если ожидаемого значения нет, см. [Устранение неполадок → секрет или ссылка не отображается](/variables/troubleshooting/reference-not-applied). + + + +## Локальная разработка + +Запустите команду **локально** с внедрёнными секретами проекта и сервиса (удобно для скриптов и миграций): + +```bash +lizard run --service api -- node scripts/seed.js +``` + +См. [`lizard run` vs. `lizard ssh`](/cli/run#run-vs-ssh). + + + +## См. также + +- [Перекрёстные ссылки между сервисами](/variables/references) — читайте значения одного сервиса из другого без копирования учётных данных. +- [`lizard secrets`](/cli/secrets) — полная справка по командам. diff --git a/_locales/ru/variables/references.mdx b/_locales/ru/variables/references.mdx new file mode 100644 index 0000000..649f4cc --- /dev/null +++ b/_locales/ru/variables/references.mdx @@ -0,0 +1,78 @@ +--- +description: "Читайте значения одного сервиса или аддона из другого с синтаксисом ${{name.KEY}}. Как ссылки разрешаются во время деплоя и почему они лучше копирования." +--- + + + +# Перекрёстные ссылки + +Ссылки позволяют одному сервису или аддону читать значения другого без копирования учётных данных. Они хранят секреты в одном месте и автоматически их вращают. + + + +## Синтаксис + +``` +${{.}} +``` + +- `` — имя целевого сервиса или аддона (то, что показано в дашборде и используется в `lizard add -n`). +- `` — ключ в объединённом окружении цели. + +Используйте их везде, где принимается значение — чаще всего в секрете: + +```bash +lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api +``` + + + +## Как они разрешаются + +- Ссылки разрешаются **во время деплоя** против объединённого окружения цели. +- Они хранятся по **ID**, поэтому переименование цели позже не ломает ссылку. +- Ссылка на **отсутствующую** цель или ключ разрешается в **пустую строку** — она *не* проваливает деплой. +- Ошибку выдают только **циклические** ссылки. + +> Поскольку отсутствующий ключ молча становится пустым, всегда проверяйте, что потребитель действительно получил значение после настройки ссылки: +> ```bash +> lizard ssh --service api -- env | grep DATABASE_URL +> ``` + +Если ссылка не отображается так, как ожидалось, см. [Устранение неполадок → секрет или ссылка не отображается](/variables/troubleshooting/reference-not-applied). + + + +## Типичные сценарии + +**Подключить аддон к нескольким сервисам** — привяжите на каждом потребителе, чтобы вращение распространилось везде: + +```bash +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api +lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service worker +``` + +**Ссылаться на значение другого сервиса** — например, делиться вычисленным URL или токеном: + +```bash +lizard secrets set UPSTREAM_URL='${{api.LIZARD_PUBLIC_DOMAIN}}' --service web +``` + +**Ссылаться на второй аддон того же типа** — используйте его сгенерированное имя: + +```bash +lizard secrets set CACHE_URL='${{redis-winter-otter.REDIS_URL}}' --service api +``` + + + +## Почему не просто `--global`? + +Размещение общего DSN в области проекта (`--global`) раскрывает его для *каждого* сервиса, включая те, которые ему не нужны. Ссылки дают тот же single-source-of-truth с вращением, сохраняя каждый секрет в области видимости только тех сервисов, которые его потребляют. См. [Область видимости секретов](/variables#scoping). + + + +## См. также + +- [Переменные и секреты](/variables) — области и приоритеты. +- [`lizard secrets`](/cli/secrets) — полный справочник команд. diff --git a/_locales/ru/variables/troubleshooting/_meta.ts b/_locales/ru/variables/troubleshooting/_meta.ts new file mode 100644 index 0000000..e15c805 --- /dev/null +++ b/_locales/ru/variables/troubleshooting/_meta.ts @@ -0,0 +1,3 @@ +export default { + 'reference-not-applied': "Секрет или ссылка не отображаются", +}; diff --git a/_locales/ru/variables/troubleshooting/reference-not-applied.mdx b/_locales/ru/variables/troubleshooting/reference-not-applied.mdx new file mode 100644 index 0000000..9c3636e --- /dev/null +++ b/_locales/ru/variables/troubleshooting/reference-not-applied.mdx @@ -0,0 +1,70 @@ +--- +description: "Ваш секрет или ссылка заданы, но сервис их не видит. Отсутствующие цели ссылок преобразуются в пустые строки, а приоритет может перекрыть значение." +--- + + + +# Секрет или ссылка не отображается в моем сервисе + +Вы задали секрет или `${{name.KEY}}` ссылку, переразвернули сервис, но работающий сервис всё равно не видит ожидаемое значение. + + + +## Что это значит + +Заданное значение никогда не попало в объединённое окружение сервиса — или что-то другое при слиянии перезаписало его до запуска приложения. + + + +## Почему это может происходить + +- **Цель ссылки или ключ не существует.** Ссылка на несуществующее имя сервиса/аддона или на ключ, который аддон не предоставляет, преобразуется в **пустую строку** вместо ошибки развёртывания. Нет никакого предупреждения — сервис просто запускается с пустым значением. +- **Что-то с более высоким приоритетом перекрыло его.** Значения объединяются в фиксированном порядке — `addon-issued env < project secrets < project env < app env < app secrets < platform vars` — поэтому секрет уровня проекта (`--global`) может быть неявно перекрыт секретом уровня сервиса с тем же ключом, а платформенные переменные (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) всегда побеждают и их невозможно переопределить. +- **Вы изменили значение времени сборки, но не пересобирали.** Большинство изменений переменных применяются без пересборки — сервис перезапускается, чтобы их подхватить. `VITE_*` и `NEXT_PUBLIC_*` — исключение: они запекаются в собранные артефакты, поэтому обычный перезапуск не подхватит новое значение; сервису нужна новая сборка. + + + +## Возможные решения + + + +### Убедитесь, что видит запущенный сервис + +Это авторитетный источник — показывает окружение живого контейнера, а не то, что вы думали, что задали: + +```bash +lizard ssh --service api -- env | grep DATABASE_URL +``` + +Если ключ отсутствует или пуст, цель ссылки/ключ неверны, или для этой области ничего не задано. Проверьте имя аддона или сервиса через `lizard ps`, а ключ — с [документированными переменными](/addons) аддона. + + + +### Проверьте на предмет коллизии областей + +Выведите секреты в обеих областях и сравните: + +```bash +lizard secrets list --service api --show +lizard secrets list --global --show +``` + +Помните: **секреты приложения перекрывают секреты проекта** — если существует значение уровня сервиса для того же ключа, оно побеждает всё, что задано через `--global`. + + + +### Пересоберите после изменения на этапе сборки + +Если изменённый ключ — `VITE_*` или `NEXT_PUBLIC_*`, запустите настоящую пересборку, а не перезапуск: + +```bash +lizard redeploy --service api +``` +См. [Время сборки vs. время выполнения](/variables#build-time-vs-runtime) и [Сборка Pipeline → что запускает пересборку](/concepts/build-pipeline#what-triggers-a-rebuild). + + + +## См. также + +- [Переменные и секреты](/variables) — области действия и приоритет. +- [Межсервисные ссылки](/variables/references) — синтаксис ссылок и их разрешение.