Deploying a HortusFox App
Introduction
HortusFox is an open-source garden and greenhouse management platform built with a modern Node.js stack. Deploying HortusFox with a Dockerfile on Klutch.sh delivers reproducible builds, managed secrets, and persistent storage for sensor data, photos, and logs—all from klutch.sh/app. This guide walks through installation, repository prep, a production-ready Dockerfile, deployment steps, Nixpacks overrides, and best practices.
Prerequisites
- A Klutch.sh account (sign up)
- A GitHub repository containing your HortusFox code (GitHub is the only supported git source)
- Docker familiarity and Node.js 18+ for local testing
- Database credentials if HortusFox uses PostgreSQL/MySQL, or API keys for any external services
- Optional object storage credentials for offloading media
Recommended architecture and ports
- Serve HortusFox over HTTP; set the internal container port to
3000. - If you run databases or MQTT/Redis sidecars on Klutch.sh, deploy them as TCP apps exposed on port
8000and connect internally on their native ports. - Persistent storage is recommended for uploads, exports, and cached telemetry.
Repository layout
hortusfox/├── apps/web/ # Frontend UI├── apps/api/ # API/backend services├── public/ # Static assets├── storage/ # Uploads and cached data (mount as a volume)├── Dockerfile # Must be at repo root for auto-detection├── package.json├── pnpm-lock.yaml # or yarn.lock / package-lock.json└── .env.example # Template only; no secretsKeep secrets out of Git; manage them as Klutch.sh environment variables.
Installation (local) and starter commands
Install dependencies and verify locally before pushing to GitHub:
pnpm installpnpm buildpnpm start -- --port 3000If your project uses migrations or seed data, add a script such as:
pnpm db:migrateOptional helper start.sh for portability and Nixpacks fallback:
#!/usr/bin/env bashset -euo pipefailpnpm db:migrate || trueexec pnpm start -- --port 3000Make it executable with chmod +x start.sh.
Dockerfile for HortusFox (production-ready)
Place this Dockerfile at the repository root; Klutch.sh auto-detects it (no Docker selection in the UI):
FROM node:18-alpine AS buildWORKDIR /app
COPY package.json pnpm-lock.yaml* yarn.lock* package-lock.json* ./RUN corepack enableRUN pnpm install --frozen-lockfile
COPY . .RUN pnpm build
FROM node:18-alpineWORKDIR /appENV NODE_ENV=production PORT=3000
COPY --from=build /app /appRUN corepack enable && pnpm install --prod --frozen-lockfile
EXPOSE 3000CMD ["pnpm", "start", "--", "--port", "3000"]Notes:
- Add any build tools you need for native modules in the build stage (for example,
apk add --no-cache python3 make g++). - Keep
storage/writable and mount it as a volume in Klutch.sh for uploads and telemetry files.
Environment variables (Klutch.sh)
Configure these in the Klutch.sh app settings (Secrets tab) before deploying:
NODE_ENV=productionPORT=3000APP_BASE_URL=https://example-app.klutch.shDATABASE_URL=(if using a database)JWT_SECRETor equivalent auth secretSTORAGE_DIR=/app/storage/uploads(or your chosen path)NEXT_PUBLIC_APP_URL=https://example-app.klutch.sh(if the frontend needs it)
If you deploy without the Dockerfile and need Nixpacks overrides:
NIXPACKS_BUILD_CMD=pnpm install --frozen-lockfile && pnpm buildNIXPACKS_START_CMD=pnpm start -- --port 3000NIXPACKS_NODE_VERSION=18
These keep HortusFox compatible with Nixpacks defaults when a Dockerfile is absent.
Attach persistent volumes
In Klutch.sh storage settings, add mount paths and sizes (no names required):
/app/storage/uploads— for images, exports, and user-generated files./app/.cache— optional cache to speed rebuilds if your app writes there.
Ensure these paths are writable inside the container.
Deploy HortusFox on Klutch.sh (Dockerfile workflow)
- Push your repository (with the Dockerfile at the root) to GitHub.
- Open klutch.sh/app, create a project, and add an app.
- Connect the GitHub repository; Klutch.sh automatically detects the Dockerfile.
- Choose HTTP traffic for HortusFox.
- Set the internal port to
3000. - Add the environment variables above (database, auth secrets, and any
NIXPACKS_*overrides if you temporarily deploy without the Dockerfile). - Attach persistent volumes for
/app/storage/uploads(and/app/.cacheif used), choosing sizes that match your data needs. - Deploy. Your app will be live at
https://example-app.klutch.sh; map a custom domain if desired.
For databases or Redis on Klutch.sh, create separate TCP apps, expose them on port 8000, and point DATABASE_URL or other service URLs to those endpoints (internal ports like 5432/6379).
Health checks and production tips
- Add a lightweight health endpoint (e.g.,
/api/health) that checks dependencies. - Keep lockfiles committed and Node versions pinned for reproducible builds.
- Monitor storage usage on mounted paths and resize before they fill.
- Back up your database regularly; do not rely on container filesystems for durability.
- Use structured logging and ship logs to your observability stack.
HortusFox on Klutch.sh combines reproducible Docker builds with managed secrets, persistent volumes, and flexible HTTP/TCP traffic options. With the Dockerfile at the repo root and ports set to 3000 for the app (8000 externally for TCP databases), you can deliver a reliable garden management experience without extra YAML or workflow overhead.