Skip to main content

daytona-cloud-server

Daytona cloud server, Den sandbox, desktop plus cloud e2e, marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den. Use for server-side setup in validated flows.

Quellinformationen

Repository
Devin-AXIS/iPolloWork
Letzte Quellaktivität
22. August 2026 um 12:37
Erkannte Sprache von SKILL.md
Englisch
Sterne
7.382
Forks
1.135

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
daytona-cloud-server
description
Daytona cloud server, Den sandbox, desktop plus cloud e2e, marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den. Use for server-side setup in validated flows.
# Daytona Cloud Server Use this skill when the user needs the hosted/server side of iPolloWork running in Daytona. This is separate from the Electron desktop sandbox. ## What This Covers - Den Web on port `3005`. - Den API on port `8788`. - Worker proxy on port `8789`. - MySQL inside the server sandbox. - Public Daytona preview URLs for Electron to consume. - Marketplace, org policy, cloud auth, and server-managed extension flows. ## Start Server Sandbox From the repo root: ```bash bash .devcontainer/test-server-on-daytona.sh [branch-or-commit] ``` The helper creates a separate server sandbox, starts MySQL, Den API, Den Web, and worker proxy, waits for health checks, then prints URLs. If dependencies or the base image changed, refresh the server snapshot: ```bash bash .devcontainer/create-daytona-ipollowork-server-snapshot.sh ``` ## Connect Electron To Server For end-to-end desktop validation, use the `daytona-electron-den` skill. This section only covers wiring the Electron sandbox to the printed server URLs. Start a second Daytona sandbox for Electron and point it at the server URLs: ```bash bash .devcontainer/test-on-daytona.sh [branch-or-commit] \ --den-base-url <DEN_WEB_URL> \ --den-api-base-url <DEN_API_URL> ``` For flows that must require cloud sign-in, add `--require-signin`. ## Validate Server Health Use the public URLs printed by the helper: ```bash curl -sf <DEN_WEB_URL>/api/den/health curl -sf <DEN_API_URL>/health ``` Inspect logs if health checks fail: ```bash daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-api.log' daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-web.log' daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-worker-proxy.log' daytona exec "$SERVER_SANDBOX" -- 'tail -120 /tmp/den-db-push.log' ``` ## When To Use Two Sandboxes Use two sandboxes when testing cloud behavior end-to-end: server sandbox for Den and a separate Electron sandbox for the desktop client. This matches production better than trying to run everything inside one desktop sandbox. Use this for marketplace install/remove/search/filter, org-managed extensions, desktop handoff auth, cloud restrictions, and worker proxy flows. ## Evidence Pair this with the `daytona-recording-artifacts` skill. Server proof should include health-check output, relevant logs, CDP assertions from Electron, and a recording or screenshot artifact for human review. Use `fraimz` for pass/fail. Server health alone does not prove Electron cloud behavior works.
Auf GitHub ansehen