Skip to content

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

  • 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 8000 and 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 secrets

Keep 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:

Terminal window
pnpm install
pnpm build
pnpm start -- --port 3000

If your project uses migrations or seed data, add a script such as:

Terminal window
pnpm db:migrate

Optional helper start.sh for portability and Nixpacks fallback:

#!/usr/bin/env bash
set -euo pipefail
pnpm db:migrate || true
exec pnpm start -- --port 3000

Make 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 build
WORKDIR /app
COPY package.json pnpm-lock.yaml* yarn.lock* package-lock.json* ./
RUN corepack enable
RUN pnpm install --frozen-lockfile
COPY . .
RUN pnpm build
FROM node:18-alpine
WORKDIR /app
ENV NODE_ENV=production PORT=3000
COPY --from=build /app /app
RUN corepack enable && pnpm install --prod --frozen-lockfile
EXPOSE 3000
CMD ["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=production
  • PORT=3000
  • APP_BASE_URL=https://example-app.klutch.sh
  • DATABASE_URL= (if using a database)
  • JWT_SECRET or equivalent auth secret
  • STORAGE_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 build
  • NIXPACKS_START_CMD=pnpm start -- --port 3000
  • NIXPACKS_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)

  1. Push your repository (with the Dockerfile at the root) to GitHub.
  2. Open klutch.sh/app, create a project, and add an app.
  3. Connect the GitHub repository; Klutch.sh automatically detects the Dockerfile.
  4. Choose HTTP traffic for HortusFox.
  5. Set the internal port to 3000.
  6. Add the environment variables above (database, auth secrets, and any NIXPACKS_* overrides if you temporarily deploy without the Dockerfile).
  7. Attach persistent volumes for /app/storage/uploads (and /app/.cache if used), choosing sizes that match your data needs.
  8. 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.