Daytona Cloud Server
SkillDev toolsThis skill sets up and runs the hosted side of iPolloWork in a Daytona cloud sandbox for testing. Once added, your AI can bring up iPolloWork's cloud components on demand so desktop and cloud flows can be tested end to end.
Available today. Use it from your connected AI after setup.
No other account needed.
After adding the skill, ask your AI to set up iPolloWork's hosted side in a Daytona sandbox. Then use it for setup as part of your validated test flows.
Then ask your AI: use the Daytona Cloud Server skill
What your AI can do with it
- Set up and run the iPolloWork hosted side in a Daytona cloud sandbox
- Set up cloud authentication and organization policies
- Run desktop-to-cloud end-to-end tests
- Connect the Electron desktop app to the Den sandbox
- Set up the marketplace and worker proxy components
What this skill tells your AI
The instructions your AI receives, as published by devin-axis/ipollowork in .opencode/skills/daytona-cloud-server/SKILL.md and read by ahel’s review.
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 .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 .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 .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:
curl -sf <DEN_WEB_URL>/api/den/health
curl -sf <DEN_API_URL>/health
Inspect logs if health checks fail:
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.
Signals
- GitHub stars
- 6k
- Forks
- 1k
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
daytona-cloud-server- Source
- github.com/devin-axis/ipollowork