Potato lokal oder in der Cloud ausführen

Potato läuft mit zwei Befehlen auf Ihrem eigenen Rechner, und potato deploy bringt dieselbe Konfiguration mit einem weiteren Befehl auf einen Cloud-Host. Diese Seite ordnet jeder häufigen Situation einen Host zu und nennt den Befehl dafür. Die Cloud-Ziele weiter unten erfordern Potato 2.10.0 oder neuer. Diese Version hat AWS, Heroku, Fly, Railway, Hetzner, Vultr, Linode und OpenStack zu den Zielen DigitalOcean, Render und HuggingFace hinzugefügt, die es in 2.9 bereits gab.

Wo eine Aufgabe laufen soll

Welcher Host passt, hängt davon ab, wie lange die Aufgabe erreichbar bleiben muss und wer dafür bezahlt. Die Kosten in der Tabelle sind die Schätzungen, die Potato 2.10.0 für die Standardgröße jedes Ziels ausgibt, und --dry-run gibt die Schätzung für die Größe aus, die Sie wählen.

Auf AWS verwenden Sie Lightsail, das --provider aws anlegt. Der Pauschalpreis enthält die IPv4-Adresse und einen 60-GB-Datenträger, und Lightsail braucht nur lightsail:*-Berechtigungen, funktioniert also auch unter einer eingeschränkten IAM-Rolle. Das EC2-Ziel (aws-ec2) ist für Konten gedacht, in denen Lightsail deaktiviert ist.

Jetstream2 ist eine von der NSF finanzierte Forschungscloud. Mit einer ACCESS-Allokation kostet sie nichts, und jede Instanz erhält einen DNS-Namen, sodass Annotatoren einen gewöhnlichen Hostnamen mit einem gewöhnlichen Zertifikat sehen. Die Standardinstanz verbraucht 2 Service Units pro Stunde, über ein Jahr etwa 17.500. Löschen Sie sie deshalb, wenn die Studie endet.

Potato auf dem eigenen Rechner ausführen

Potato braucht Python 3.9 oder neuer. Installieren Sie es und starten Sie eine Aufgabe:

pip install potato-annotation
potato start myproject/config.yaml -p 8000

Die Aufgabe ist unter http://localhost:8000 erreichbar, und niemand sonst kann darauf zugreifen. potato start liest die Konfigurations- und Datendateien dort, wo sie liegen, sodass ein Neustart eine Änderung übernimmt. Deshalb ist es der richtige Befehl, solange Sie an einer Aufgabe arbeiten. Der Schnellstart erstellt eine erste Konfiguration, und Installation behandelt die optionalen Extras und virtuelle Umgebungen.

Das veröffentlichte Docker-Image braucht kein Python auf dem Host. Es enthält Potato und seine Abhängigkeiten, und Ihr Projektordner mit config.yaml und den zugehörigen Daten wird unter /app eingebunden:

docker run -p 8000:7860 -v "$PWD/myproject:/app" ghcr.io/davidjurgens/potato:latest

Der Container lauscht auf Port 7860, den der Befehl auf Port 8000 Ihres Rechners abbildet. Produktionseinrichtung behandelt die Tags des Images, seine Umgebungsvariablen und den Fehler beim Dateibesitz, den Linux-Hosts melden.

Ein temporärer öffentlicher Link mit potato share

potato share führt die Aufgabe aus und macht sie über einen öffentlichen HTTPS-Link erreichbar, solange der Befehl läuft. Dafür braucht es einen Tunnel-Client und verwendet cloudflared, Tailscale oder ngrok, in dieser Reihenfolge, je nachdem, was installiert ist:

brew install cloudflared
potato share myproject/config.yaml

Der Link funktioniert nicht mehr, sobald Sie Ctrl-C drücken, der Laptop in den Ruhezustand geht oder sich das Netzwerk ändert, und die Annotationen bleiben auf Ihrem eigenen Datenträger. Bevor potato share den Tunnel öffnet, zeigt es an, wer sich anmelden kann, und bittet Sie um Bestätigung, weil die Anmelderegeln der Konfiguration dann für alle gelten, die den Link haben. Manche Hochschulnetze sperren trycloudflare.com-Links, und --backend tailscale umgeht die Sperre. Nutzen Sie potato share für eine Pilotstudie oder eine Laborbesprechung und einen Cloud-Host für jede Aufgabe, zu der eine teilnehmende Person am nächsten Tag zurückkehren könnte.

Mit einem Befehl in der Cloud bereitstellen

potato deploy up nimmt die Konfiguration, die Sie bereits haben, legt den Server an, besorgt ein HTTPS-Zertifikat, lädt das Projekt hoch, startet die Aufgabe und gibt die URL aus. Installieren Sie das Extra für Ihr Ziel und sehen Sie sich den Plan an, bevor Sie ihn ausführen:

pip install 'potato-annotation[deploy]'            # most targets
pip install 'potato-annotation[deploy-aws]'        # the three AWS targets
pip install 'potato-annotation[deploy-openstack]'  # Jetstream2 and other OpenStack clouds
 
potato deploy up myproject/config.yaml --provider aws --dry-run
potato deploy up myproject/config.yaml --provider aws

--dry-run braucht kein Konto. Es gibt jede Ressource aus, die das Deployment anlegen würde, die monatlichen Kosten und jede Einstellung in Ihrer Konfiguration, die auf einem öffentlichen Server riskant ist. Ohne --dry-run zeigt Potato denselben Plan und wartet auf Ihre Bestätigung, bevor es etwas anlegt. Ein erneutes up mit derselben Konfiguration aktualisiert das bestehende Deployment, und nach dem ersten up brauchen status, logs, pull und destroy kein --provider mehr.

Die dreizehn Cloud-Ziele

Potato 2.10.0 stellt auf dreizehn Cloud-Ziele bereit. Sie unterscheiden sich vor allem darin, ob der Datenträger einen Neustart übersteht, und davon hängt ab, ob ein Deployment das im nächsten Abschnitt beschriebene Backup braucht.

Die sieben VM-Ziele (aws, aws-ec2, openstack, hetzner, vultr, linode und digitalocean) werden auf dieselbe Weise eingerichtet. Jedes erhält einen eigens für dieses Deployment erzeugten Deploy-Schlüssel, eine Firewall, die nur die Ports 22, 80 und 443 öffnet, Caddy mit einem Let's-Encrypt-Zertifikat und Potato als systemd-Dienst, und potato deploy logs und pull funktionieren auf allen. Fly, Railway, Render und ECS Express führen das veröffentlichte Image aus und laden Ihr Projekt herunter, wenn der Container startet. Railway, Render und ECS Express holen es aus dem Backup-Speicher, daher brauchen alle drei --backup, und ein Railway- oder Render-Service mit Datenträger braucht es ebenfalls. Auf Fly reist ein Projekt unter 512 KB in der Konfiguration der Machine mit und braucht keinen Speicher.

Google Cloud Run, Azure Container Apps und AWS App Runner sind keine Ziele. Der Speicher, den Cloud Run und Azure Container Apps anbieten, kann eine SQLite-Datenbank nicht sicher halten, und App Runner nimmt seit dem 30. April 2026 keine neuen Kunden mehr an. Auf Azure funktioniert eine VM, die das Docker-Image ausführt.

Backups für Hosts, die ihren Datenträger löschen

Auf Heroku, ECS Express, dem kostenlosen Tarif von Render und HuggingFace Spaces wird der Datenträger gelöscht, wenn der Server neu startet. --backup kopiert alle fünf Minuten die Annotationsausgabe und Snapshots der Projektdatenbanken in ein HuggingFace-Dataset oder einen S3-Bucket und stellt sie wieder her, wenn ein Server mit leerem Datenträger startet:

potato deploy up myproject/config.yaml --provider heroku --backup hf --hf-token hf_...
potato deploy up myproject/config.yaml --provider heroku --backup s3 --s3-bucket my-bucket

Heroku und ECS Express verweigern ein Deployment ohne --backup, es sei denn, --demo erklärt die Annotationen für verzichtbar. Die Wiederherstellung bringt zusammen mit den Annotationen die Kontenliste zurück, sodass sich Annotatoren mit denselben Passwörtern anmelden und dort weitermachen, wo sie aufgehört haben, und sie überschreibt nie Annotationen, die bereits auf dem Datenträger liegen. --s3-endpoint schickt das S3-Backup an Cloudflare R2, Backblaze B2, MinIO oder einen Objektspeicher der Hochschule. Das Backup funktioniert auch auf den VM-Zielen, wo es eine zweite Kopie der Daten außerhalb des Servers vorhält.

Außerhalb von potato deploy erledigt ein backup-Block in der Konfiguration dieselbe Aufgabe auf einem Server, den Sie selbst betreiben. Installieren Sie das Extra hosting, das die Clients für HuggingFace und S3 mitbringt, setzen Sie HF_TOKEN in der Umgebung des Servers und fügen Sie diesen Block in eine bestehende Konfiguration ein:

backup:
  schedule_minutes: 5
  restore_on_boot: true
  sinks:
    - type: huggingface
      repo_id: lab/pilot-annotations

Annotationen vor destroy herunterladen

potato deploy pull lädt alles, was ein Deployment gesammelt hat, in ein Verzeichnis mit Zeitstempel herunter und prüft, was angekommen ist, und potato deploy destroy entfernt den Server. Führen Sie die beiden in dieser Reihenfolge aus:

potato deploy pull myproject/config.yaml
potato deploy destroy myproject/config.yaml

destroy weigert sich, ein Deployment zu entfernen, von dem nie ein Pull gemacht wurde, und ein Pull, der null Dateien liefert, zählt nicht. Der Pull kopiert project.sqlite über den Backup-Befehl von SQLite statt als Datei, weil einer Dateikopie einer Datenbank im WAL-Modus neuere Arbeit fehlen kann. Auf Fly und Railway löscht das Entfernen der App auch ihr Volume, sodass der Pull die einzige Kopie ist, sofern Sie nicht zusätzlich ein Backup ausgeführt haben.

Deploy-Buttons für die Konten anderer

potato deploy button schreibt die Dateien, die eine Hosting-Plattform liest, um ein Deployment mit einem Klick aus Ihrem Git-Repository anzubieten, und gibt das Badge für die README aus. Nutzen Sie es, wenn Kooperationspartner, Studierende oder ein anderes Labor Ihre Aufgabe in ihren eigenen Konten betreiben sollen:

potato deploy button studies/pilot/config.yaml --target heroku \
    --backup hf --hf-backup-repo lab/pilot-annotations

Die Ziele sind heroku, render, aws und railway. Das Ziel aws schreibt eine CloudFormation-Vorlage für „Launch Stack“, die eine Lightsail-Instanz anlegt, und für railway gibt der Befehl die nötigen Schritte aus, weil Railway Vorlagen über sein Dashboard veröffentlicht. Ihre config.yaml bleibt unverändert, und der Befehl schreibt daneben eine Kopie, potato.deploy.yaml, mit angewendeten Deployment-Einstellungen. Es gelangen keine Geheimnisse ins Repository. Heroku, Render und die AWS-Vorlage erzeugen die Sitzungs- und Admin-Schlüssel beim Deployment. Die Buttons für Heroku, Render und AWS erfordern --backup, und die Person, die bereitstellt, liefert die Zugangsdaten dafür.

Weiterführende Informationen

Jedes Ziel hat eine eigene Seite in der Potato-Dokumentation:

• Potato installieren und ausführen und Eine Aufgabe bereitstellen, der vollständige Lebenszyklus von potato deploy
• AWS: Lightsail, EC2 und ECS Express, mit den IAM-Berechtigungen, die jedes braucht
• Jetstream2 und OpenStack, einschließlich der Beantragung einer Allokation
• Hetzner, Vultr und Linode sowie DigitalOcean
• Fly.io, Railway, Render, Heroku und HuggingFace Spaces
• Backups, Annotationen zurückholen und Deploy-Buttons
• Eine Aufgabe über eine temporäre URL teilen

Auf dieser Website behandelt Produktionseinrichtung den Betrieb von Potato unter gunicorn und Docker auf einem Server, den Sie selbst verwalten, und Reverse-Proxy die Bereitstellung unter einem URL-Pfadpräfix.