Add Nebulynk Template - #1086

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Tested this on a Dokploy instance (hostinger.dokploy.com) by importing blueprints/nebulynk from this branch (merged with canary). It deploys and works; I pushed one small cleanup and have a few non-blocking suggestions below.

Upstream / legitimacy

• sapientorius/Nebulynk: created 2026-03-06, 79 commits, releases v0.2.0 → v0.5.0 (2026-08-01 → 2026-08-19), ci.yml + release.yml green, Dependabot PRs, BSL 1.1 license (source-available, named licensor), ~3.7 MB of JS/Vue + a Rust (Tauri) PTT helper, website nebulynk.net live. Author account dates from 2015. 114★ but 0 forks / 0 watchers; GitHub's stargazer listing was returning 404 for every repo at review time, so I could not audit the stargazers. No prebuilt images: everything is built from the repo (build.context: https://github.com/sapientorius/Nebulynk.git#stable), so image↔repo correspondence is inherent.

Conventions

• No container_name, no dokploy-network, no Traefik labels, expose for HTTP services, secrets via ${password:N}/${hash:N}, per-template meta.json with logo. Host ports 7881/tcp + 7882/udp are only for LiveKit WebRTC media and are declared with the # dokploy: allow-host-ports marker (same pattern as fonoster/mailu/etc.). generate-meta.js --check, validate-docker-compose.ts and validate-template.ts all pass.
• I pushed 08e0637 removing blueprints/nebulynk/import.base64 — the build scripts don't use it and it duplicates the compose/toml (and would go stale on every edit).

Deploy results (fix-nebulynk, deploy done in 123 s, builds included)

• Containers: frontend, backend, livekit, livekit-egress, garage, postgres, redis all running, RestartCount 0; garage-volume-init exited 0.
• Logs: backend Ran 70 migration(s), Storage initialized (bucket: nebulynk-files), Socket.IO initialized, Nebulynk API started on http://localhost:3030; garage Creating default access key / Creating default bucket nebulynk-files and a successful authenticated HEAD /nebulynk-files/ from the backend; livekit starting LiveKit server v1.13.4 with the public IP found via STUN; egress service ready.
• Via Traefik: frontend / → 200 «Nebulynk»; backend / → Feathers JSON 404 (app-level), POST /authentication → 401 Invalid login, GET /users → 401 Not authenticated, CORS preflight from the frontend origin → 204 with access-control-allow-origin: http://<frontend-domain> (FRONTEND_URL wiring OK); livekit / → OK, /rtc websocket upgrade → 401 (expects a token, correct); garage / → 403 AccessDenied (S3 API reachable, anonymous access denied); host port 7881/tcp reachable from outside.

Non-blocking suggestions

1. source_ref = "stable" (and meta.json "version": "stable") is a moving branch — the equivalent of :latest. Consider defaulting to the release tag (v0.5.0) and bumping it per release so deployments are reproducible; stable can stay documented as the opt-in channel.
2. garage, livekit and livekit-egress are built from source only to COPY a config file into the official image. The same can be done without any build by using the official pinned images plus [[config.mounts]] in template.toml (filePath = "livekit.yaml" etc.) mounted into the container — it removes three image builds from every deploy.
3. NODE_ENV=development as the shipped default is unusual for a template; if the only reason is plain-HTTP cookies, it may be worth gating that behaviour on a dedicated flag instead so production can be the default.
4. version: "3.8" at the top of the compose file is obsolete (harmless).
5. One note for maintainers: the project is BSL 1.1 (source-available, not OSI), in case that matters for inclusion.

Service left running for a few minutes for inspection and then removed.

Thank you for the review and for testing the template end-to-end. I also pulled your cleanup commit removing import.base64.

I have now replaced the Garage, LiveKit, and LiveKit Egress source builds with their pinned upstream images and Dokploy-managed config mounts. The original non-root users are preserved, and I generated a fresh import payload for a Dokploy deployment test.

For now, I deliberately kept NEBULYNK_SOURCE_REF=stable and NODE_ENV=development:

• stable remains the intended opt-in rolling channel for this template, with the acknowledged reproducibility trade-off.
• The generated template domains are HTTP-only until TLS is configured. Switching the default to production would make the initial HTTP smoke-test path unreliable because of secure-cookie behaviour. Operators should switch to HTTPS/WSS URLs and NODE_ENV=production once TLS is enabled.