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.

Informações da origem

Repositório
Devin-AXIS/iPolloWork
Última atividade na origem
22 de agosto de 2026 às 12:37
Idioma detectado do SKILL.md
inglês
Estrelas
6.997
Forks
1.136

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
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.
Ver no GitHub