Deployment Profiles¶
Kamerplanter is modular by design. You decide which components to run — from a lean setup on a Raspberry Pi to a full multi-tenant deployment on Kubernetes. This page helps you find the right bundle of components for your use case.
Complete feature-by-feature reference
This page shows five recommended bundles for typical use cases. For an exhaustive table of all ~40 features with the exact environment variable, mandatory secrets, and resource impact, see the Configuration Matrix.
Component Overview¶
Every Kamerplanter installation consists of a core (always required) and optional components that you enable as needed.
Core (always active)¶
| Component | Purpose |
|---|---|
| Backend (FastAPI) | REST API, business logic, phase control, fertilization plans |
| Frontend (React) | Web interface |
| ArangoDB | Primary database (documents + graph queries) |
| Valkey (Redis-compatible) | Cache and Celery broker |
| Celery Worker + Beat | Background tasks (care reminders, data enrichment, AI tips) |
Optional Components¶
| Component | Purpose | Resource requirements | Configuration |
|---|---|---|---|
| Operating mode | light = no login, single user; full = JWT auth, multi-tenant | — | KAMERPLANTER_MODE |
| AI assistant (backend side) | Unlocks the /ai/* endpoints, care tips, diagnostics, glossary | 128 MB – 2 GB RAM (backend, without the LLM) | AI_FEATURES_ENABLED + KNOWLEDGE_SERVICE_ENABLED/KNOWLEDGE_SERVICE_URL |
| Ollama | Local language model execution (no data leaves your network) | 4–16 GB RAM, optional GPU | Docker profile ollama; LLM_PROVIDER=ollama on the Knowledge Service |
| Knowledge Service | RAG pipeline: search knowledge base, connect the LLM provider, enrich context | 128 MB – 512 MB RAM | Dedicated Helm controller (controllers.knowledge-service), no pre-stubbed enabled flag in values.yaml — the operator supplies the full block |
| VectorDB (pgvector) | Vector store for RAG embeddings and for the plant/pest recognition reference index (REQ-029-A) | 128 MB – 512 MB RAM | controllers.vectordb.enabled (pre-defined in values.yaml, defaults to false) |
| Embedding Service | ONNX-based embedding computation (no PyTorch) | 1.5–4 GB RAM | Dedicated Helm controller (controllers.embedding-service), no pre-stubbed enabled flag |
| Reranker Service | Cross-encoder re-ranking for higher RAG precision (ADR-007) | 1.5–4 GB RAM | RERANKER_URL on the Knowledge Service (empty = disabled) |
| TimescaleDB | Time-series sensor data, automatic downsampling | 256–512 MB RAM | TIMESCALEDB_ENABLED |
| Home Assistant | Sensor and actuator integration (temperature, humidity, lights) | External | HA_URL + HA_ACCESS_TOKEN |
| External enrichment | Auto-enrich plant data from GBIF and Perenual | — | PERENUAL_API_KEY |
AI assistant — operator switch and provider choice are separate
AI_FEATURES_ENABLED is a pure backend switch (stage 1 of the three-stage unlock mechanism, see For Technical Users / Self-Hosters): false makes all /ai/* endpoints answer with HTTP 404. It does not decide which language model is used — that is LLM_PROVIDER (ollama, anthropic, openai_compatible) on the standalone Knowledge Service (src/knowledge-service/), not on the backend. There is no AI_DEFAULT_PROVIDER, no AI_OLLAMA_URL/AI_OLLAMA_MODEL, and no AI_FALLBACK_PROVIDER on the backend — these variables, documented here previously, do not exist in the code. Details: AI Provider Setup, Environment Variables — AI Assistant.
Profiles at a Glance¶
The following matrix shows five predefined profiles. Each profile is a recommendation — you can always add or remove individual components.
| Minimal | Hobby | Standard | Professional | SaaS | |
|---|---|---|---|---|---|
| Infrastructure | Docker Compose | Docker Compose | Docker Compose / K8s | Kubernetes | Kubernetes |
| Operating mode | Light | Light | Full | Full | Full |
| AI assistant | — | Ollama (local) | Ollama (local) | Ollama (local) | Cloud (OpenAI / Anthropic) |
| Knowledge Service + Embedding Service + VectorDB | — | Yes (required bundle for Ollama) | Yes (required bundle for Ollama) | Yes | Yes |
| Reranker Service | — | — | Optional | Optional | Yes |
| TimescaleDB | — | — | Optional | Yes | Yes |
| Home Assistant | — | Optional | Optional | Yes | Optional |
| External enrichment | — | Optional | Yes | Yes | Yes |
| Celery Worker | Yes | Yes | Yes | Yes | Yes |
| Target audience | Raspberry Pi, quick trial | Hobby grower, home server | Engaged hobbyists, small community gardens | Indoor growing, large community gardens | Managed hosting, multiple tenants |
| Total RAM | ~1 GB | ~3 GB | ~4 GB | ~6 GB | ~8 GB |
Minimal¶
Target audience¶
You want to try Kamerplanter quickly or only have a few houseplants. A Raspberry Pi ⅘ or an old laptop is sufficient. You need neither login nor AI.
Requirements¶
- Docker + Docker Compose
- 1 GB free RAM, 2 GB disk space
- Raspberry Pi 4 (2 GB), Raspberry Pi 5, NUC, laptop
Active components¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- AI assistant
- TimescaleDB
- Home Assistant
- Knowledge Service / RAG
Example configuration¶
services:
arangodb:
image: arangodb:3.11
# ...
valkey:
image: valkey/valkey:8-alpine
# ...
backend:
build: ./src/backend
environment:
KAMERPLANTER_MODE: light
AI_FEATURES_ENABLED: "false"
TIMESCALEDB_ENABLED: "false"
depends_on: [arangodb, valkey]
celery-worker:
build: ./src/backend
command: celery -A app.tasks worker --loglevel=info
depends_on: [arangodb, valkey]
celery-beat:
build: ./src/backend
command: celery -A app.tasks beat --loglevel=info
depends_on: [arangodb, valkey]
frontend:
build: ./src/frontend
environment:
KAMERPLANTER_MODE: light
depends_on: [backend]
What you gain by upgrading¶
Without the AI assistant you get no automatic care tips or diagnostics. You can add Ollama at any time without losing data.
Hobby¶
Target audience¶
You have 10–50 plants and a home server (NAS, old desktop, NUC). You want AI-powered care tips, but your data should not leave your network. You do not need login — you are the only user.
Requirements¶
- Docker + Docker Compose
- 6–8 GB free RAM for the AI stack (Ollama model + Knowledge/Embedding Service/VectorDB overhead — see Configuration Matrix), more with a 7B model, optional GPU
- Home server, NUC, desktop PC
Active components¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- Ollama (local language model)
- Knowledge Service + Embedding Service + VectorDB (required so the AI assistant can actually reach Ollama)
- TimescaleDB
- Home Assistant (optional)
- External enrichment (optional)
Ollama alone is not enough
The backend never talks to Ollama directly. The provider connection (LLM_PROVIDER) lives on the Knowledge Service — it calls Ollama and returns the result to the backend via KNOWLEDGE_SERVICE_URL. Without a running Knowledge Service (+ Embedding Service for similarity search, + VectorDB as the vector store), the AI endpoints stay non-functional even if Ollama is running.
Example configuration¶
services:
# ... core as in Minimal ...
backend:
build: ./src/backend
environment:
KAMERPLANTER_MODE: light
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: http://knowledge-service:8000
INTERNAL_SERVICE_TOKEN: ${INTERNAL_SERVICE_TOKEN} # openssl rand -hex 32
TIMESCALEDB_ENABLED: "false"
depends_on: [arangodb, valkey]
knowledge-service:
build: ./src/knowledge-service
environment:
LLM_PROVIDER: ollama
LLM_API_URL: http://ollama:11434
LLM_MODEL: gemma3:4b
EMBEDDING_SERVICE_URL: http://embedding-service:8080
VECTORDB_HOST: vectordb
INTERNAL_SERVICE_TOKEN: ${INTERNAL_SERVICE_TOKEN}
depends_on: [ollama, embedding-service, vectordb]
embedding-service:
build: ./docker/embedding-service
vectordb:
build: ./docker/vectordb
ollama:
image: ollama/ollama:latest
volumes:
- ollama_models:/models
# GPU passthrough (optional):
# deploy:
# resources:
# reservations:
# devices:
# - capabilities: [gpu]
Model selection
Start with gemma3:4b — it runs on most machines from 2020 onwards without a GPU. For details on model selection, see AI Provider Setup.
What you gain by upgrading¶
Without full mode you cannot invite additional users. Without TimescaleDB, sensor data is not stored long-term. Both can be enabled later.
Standard¶
Target audience¶
You are an engaged hobbyist or run a small community garden. Multiple people should have their own accounts. You want AI tips and optionally store sensor data long-term.
Requirements¶
- Docker Compose or Kubernetes cluster
- 6–8 GB free RAM (AI stack as in the Hobby profile above)
- Server, NUC, or small K8s cluster
Active components¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- Ollama + Knowledge Service + Embedding Service + VectorDB (AI stack as a bundle, see the Hobby profile)
- External enrichment (GBIF + Perenual)
- Reranker Service (optional — higher RAG precision)
- TimescaleDB (optional)
- Home Assistant (optional)
Example configuration¶
services:
# ... core + Ollama + Knowledge Service + Embedding Service + VectorDB (see the Hobby profile) ...
backend:
build: ./src/backend
environment:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: http://knowledge-service:8000
INTERNAL_SERVICE_TOKEN: ${INTERNAL_SERVICE_TOKEN}
JWT_SECRET_KEY: ${JWT_SECRET_KEY} # openssl rand -hex 32
PERENUAL_API_KEY: ${PERENUAL_API_KEY}
TIMESCALEDB_ENABLED: ${TIMESCALEDB_ENABLED:-false}
depends_on: [arangodb, valkey]
controllers:
backend:
containers:
main:
env:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: "http://kamerplanter-knowledge-service:8000"
TIMESCALEDB_ENABLED: "false"
knowledge-service:
enabled: true
containers:
main:
env:
LLM_PROVIDER: ollama
LLM_API_URL: "http://kamerplanter-ollama:11434"
LLM_MODEL: gemma3:4b
TimescaleDB only needed with sensors
If you do not plan to connect sensors or Home Assistant, you can skip TimescaleDB. Manual measurements (pH, EC) are stored in ArangoDB. TimescaleDB becomes useful only with automatic, high-frequency data collection.
What you gain by upgrading¶
Without TimescaleDB there is no automatic downsampling of sensor data. Without Home Assistant there is no automatic sensor collection or actuator control. Without the Reranker Service, RAG answer quality is somewhat lower (plain hybrid search instead of cross-encoder re-ranking).
Professional¶
Target audience¶
You run professional indoor growing or a large community garden with role management. Sensors and actuators are connected via Home Assistant. You want seamless time-series storage and AI diagnostics with the full RAG context (re-ranking for higher hit quality).
No automatic cloud fallback
The Knowledge Service uses one configured LLM_PROVIDER (ollama, anthropic, or openai_compatible) — there is no automatic runtime fallback from Ollama to a cloud provider if it becomes unreachable. Switching providers is a deliberate configuration change (a Knowledge Service redeploy). If Ollama is unreachable, the AI assistant reports an error — the rest of the application is unaffected.
Requirements¶
- Kubernetes cluster (3+ nodes recommended)
- 6–8 GB RAM for Kamerplanter pods
- Home Assistant instance on the network
- Optional: GPU node for faster AI inference
Active components¶
- Backend + Frontend
- ArangoDB + Valkey
- Celery Worker + Beat
- Ollama (local language model,
mistral:7b) - Knowledge Service + VectorDB + Embedding Service
- Reranker Service (cross-encoder re-ranking)
- TimescaleDB
- Home Assistant
- External enrichment (GBIF + Perenual)
Example configuration¶
controllers:
backend:
containers:
main:
env:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: "http://kamerplanter-knowledge-service:8000"
TIMESCALEDB_ENABLED: "true"
TIMESCALEDB_HOST: timescaledb
HA_URL: http://homeassistant.home:8123
HA_ACCESS_TOKEN:
secretKeyRef:
name: kamerplanter-secrets
key: ha-access-token
PERENUAL_API_KEY:
secretKeyRef:
name: kamerplanter-secrets
key: perenual-api-key
envFrom:
- secret: kamerplanter-secrets # carries INTERNAL_SERVICE_TOKEN (mandatory from here on), among others
timescaledb:
enabled: true
knowledge-service:
enabled: true
containers:
main:
env:
LLM_PROVIDER: ollama
LLM_API_URL: "http://kamerplanter-ollama:11434"
LLM_MODEL: mistral:7b
RERANKER_URL: "http://kamerplanter-reranker-service:8081"
RERANKER_INITIAL_K: "20"
RERANKER_TOP_K: "5"
reranker-service:
enabled: true
containers:
main:
env:
RERANKER_MODEL: "bge-reranker-v2-m3"
embedding-service:
enabled: true
vectordb:
enabled: true
Keep secrets out of values.yaml
API keys and tokens belong in Kubernetes Secrets or an external secret manager (e.g., Sealed Secrets, External Secrets Operator). Use secretKeyRef in the Helm values.
What you gain by upgrading¶
In the Professional profile you run a single instance for your organization with a local language model. The SaaS profile adds multi-tenant isolation, horizontal scaling, and a cloud language-model provider in place of Ollama.
SaaS / Multi-Tenant¶
Target audience¶
You operate Kamerplanter as a platform for multiple independent tenants (gardens, businesses, communities). Each tenant has its own data, roles, and settings. You need horizontal scaling and reliable cloud AI.
Requirements¶
- Kubernetes cluster with autoscaling
- 8+ GB RAM for Kamerplanter pods
- Managed database services recommended (ArangoDB Oasis, managed PostgreSQL)
- Cloud AI provider account (OpenAI or Anthropic)
Active components¶
- Backend + Frontend (multiple replicas)
- ArangoDB + Valkey
- Celery Worker (multiple replicas) + Beat
- Cloud language model (Anthropic or an OpenAI-compatible endpoint) instead of Ollama
- Knowledge Service + VectorDB + Embedding Service
- TimescaleDB
- External enrichment (GBIF + Perenual)
- Home Assistant (optional, tenant-specific)
Example configuration¶
controllers:
backend:
replicas: 3
containers:
main:
env:
KAMERPLANTER_MODE: full
AI_FEATURES_ENABLED: "true"
KNOWLEDGE_SERVICE_ENABLED: "true"
KNOWLEDGE_SERVICE_URL: "http://kamerplanter-knowledge-service:8000"
TIMESCALEDB_ENABLED: "true"
knowledge-service:
enabled: true
containers:
main:
env:
LLM_PROVIDER: openai_compatible
LLM_API_URL: "https://api.openai.com/v1"
LLM_MODEL: gpt-4o-mini
LLM_API_KEY:
secretKeyRef:
name: kamerplanter-secrets
key: llm-api-key
celery-worker:
replicas: 2
frontend:
replicas: 2
Anthropic as an alternative
For Anthropic directly (instead of an OpenAI-compatible endpoint), set LLM_PROVIDER: anthropic — LLM_API_URL is then not needed, LLM_API_KEY remains mandatory. LLM_PROVIDER only accepts ollama, anthropic, and openai_compatible — a bare openai is not a valid value.
Managed databases
In SaaS operation, consider using managed database services instead of self-hosted containers. This significantly reduces operational overhead for backups, updates, and high availability.
Build Your Own Profile¶
The profiles above are recommendations. You can enable or disable any component individually by setting the corresponding environment variables:
| Decision | Variable | Values |
|---|---|---|
| Login and multi-tenant? | KAMERPLANTER_MODE | light / full |
| Unlock the AI assistant instance-wide? (backend) | AI_FEATURES_ENABLED | true / false |
| Connect the AI assistant to the Knowledge Service? (backend) | KNOWLEDGE_SERVICE_ENABLED + KNOWLEDGE_SERVICE_URL | true/false + HTTP URL |
| Which language model? (Knowledge Service, not the backend) | LLM_PROVIDER | ollama, anthropic, openai_compatible |
| Sensor time-series? | TIMESCALEDB_ENABLED | true / false |
| Re-ranking (higher precision)? (Knowledge Service) | RERANKER_URL | HTTP URL of the reranker service (empty = disabled) |
| Home Assistant? | HA_URL + HA_ACCESS_TOKEN | URL + token (empty = disabled) |
| Plant data enrichment? | PERENUAL_API_KEY | API key (empty = GBIF only) |
VECTORDB_ENABLED is not a backend switch
VECTORDB_ENABLED appears in .env.example as a pure Docker Compose profile flag (docker-compose --profile vectordb up) — it is not an environment variable read by the Kamerplanter backend and controls nothing there. The backend enables the AI/RAG chain exclusively via KNOWLEDGE_SERVICE_ENABLED (AI assistant) and INFERENCE_SERVICE_ENABLED (plant/pest photo recognition, see Setting Up Plant Identification).
In Docker Compose, enable optional services via profiles:
# Core only:
docker compose up -d
# With Ollama and TimescaleDB:
docker compose --profile ollama --profile timescaledb up -d
# With RAG (Knowledge Service + VectorDB + Reranker):
docker compose --profile ollama --profile timescaledb --profile vectordb up -d
Reranker in the Docker Compose vectordb profile
The reranker-service is assigned to the vectordb Docker Compose profile and starts together with the Knowledge Service and VectorDB. The reranker is more resource-intensive than the embedding service and VectorDB — on low-powered hardware you can leave RERANKER_URL empty to use hybrid search without re-ranking.
For a complete list of all environment variables, see Environment Variables.
Decision Guide¶
The following flowchart helps you find a suitable profile:
flowchart TD
A[How many users?] -->|Just me| B{Do you need AI tips?}
A -->|2-10 people| D{Kubernetes available?}
A -->|10+ / tenants| G[SaaS / Multi-Tenant]
B -->|No| C[Minimal]
B -->|Yes| E[Hobby]
D -->|No| F[Standard<br/>Docker Compose]
D -->|Yes| H{Sensors / HA?}
H -->|No| F2[Standard<br/>Kubernetes]
H -->|Yes| I[Professional] Frequently Asked Questions¶
Can I upgrade to a larger profile later?¶
Yes. All profiles use the same database. You can add components at any time (e.g., enable Ollama, start TimescaleDB, switch from light to full mode) without losing data. When switching from light to full mode, you need to set a password for the existing system user once.
Can I run Ollama on a Raspberry Pi?¶
Yes, starting with the Raspberry Pi 5 with 8 GB RAM. Use a small model like llama3.2:3b. Response times are 15–30 seconds per tip — acceptable but not fast. The Raspberry Pi 4 does not have sufficient performance for larger models.
Do I need TimescaleDB without sensors?¶
No. Without automatic sensor data collection (IoT/MQTT or Home Assistant), TimescaleDB provides no benefit. Manual measurements (pH, EC) are stored in ArangoDB. You can enable TimescaleDB later when you connect sensors.
What happens if I do not configure an AI provider?¶
Kamerplanter works fully without AI. The default AI_FEATURES_ENABLED=false makes all /ai/* endpoints answer with HTTP 404, as if they did not exist — the AI tip cards, the glossary, and the AI diagnosis then do not appear in the interface. All rule-based features (phase control, fertilization plans, care reminders) operate independently of this.
See also¶
- Configuration Matrix — Exhaustive reference of all features with their switch, mandatory secrets, and resource impact
- Light Mode — Details on running without authentication
- AI Provider Setup — Configure Ollama, OpenAI, Anthropic, and other providers
- Home Assistant Integration — Sensor and actuator integration
- Environment Variables — Complete variable reference
- Kubernetes — Cluster setup and deployment
- Infrastructure — Skaffold Profiles — Skaffold modules (
-m ki) for the AI stack