Build and self-host your own AI app

ssh root@<SERVER_IP>
apt update
apt upgrade -y
reboot

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

# Commit this file with names and fake placeholders only
REPLICATE_API_TOKEN=
REPLICATE_MODEL=owner/model-name
AUTH_SECRET=
APP_PASSWORD_HASH=
DATABASE_PATH=/app/data/app.db

# Keep real local values here (never commit)
# .env.local

# .gitignore must include
.env*
!.env.example

Build and deploy a private, mobile-first AI calorie tracker. Continue through implementation, deployment and live verification. Do not stop after planning, scaffolding or a local build.

PROJECT VALUES
- App name: APP_NAME
- Local working folder: LOCAL_PATH
- GitHub owner/repository: GITHUB_OWNER/REPO_NAME
- Production domain: DOMAIN
- Coolify URL: COOLIFY_URL
- Coolify API token file: COOLIFY_TOKEN_FILE_PATH
- Replicate token file: REPLICATE_TOKEN_FILE_PATH
- Single-user login secret or password-hash file: AUTH_SECRET_FILE_PATH
- Preferred Replicate model: REPLICATE_MODEL (confirm its current official model page and API schema before coding)

NON-NEGOTIABLE SAFETY
1. Treat every token and password as secret. Read the named files only when required. Never print, echo, log, screenshot, paste into chat, include in command output, or commit their contents.
2. Use obvious fake placeholders in .env.example. Put real local values in .env.local, confirm it is ignored, and put production values in Coolify's encrypted environment variables.
3. Keep every Replicate call server-side. Never use NEXT_PUBLIC_ for a secret and never send the Replicate token to the browser.
4. Use official current documentation for Next.js, Coolify and Replicate APIs. Do not rely on remembered endpoints or stale examples.
5. Before pushing, inspect the staged diff and repository history for secret-shaped values. If a secret is exposed, stop, tell me which credential needs rotation without repeating it, rotate it, then continue.

BUILD THE APP
1. Inspect LOCAL_PATH first. Reuse any existing app, repository, branch, components and deployment configuration. Do not create a duplicate repository or second app resource.
2. Use the current stable Next.js App Router with TypeScript. Keep the dependency list small and use the repository's existing package manager.
3. Build a fast, installable PWA with a web app manifest, app icons and a clear offline state. It must work at 320px wide, with 44px tap targets, safe-area spacing, strong focus states, reduced-motion support and no horizontal overflow.
4. Add single-user authentication with a secure password hash, an HttpOnly Secure SameSite cookie, session expiry, logout, rate limiting on login and protected app/API routes. Do not store a plaintext password.
5. Store meals, food items, estimated calories, protein/carbs/fat, notes, timestamps and AI-request status in SQLite. Add explicit migrations and a documented migration command.
6. Mount SQLite under one configurable data directory such as /app/data. Run exactly one application replica. SQLite must live on a persistent Coolify volume and survive container replacement.
7. Let the user type or photograph a meal. Send the request from a protected server route to REPLICATE_MODEL, validate the model output, show the estimate as editable before saving, and handle timeouts, invalid output and model errors without losing the user's input.
8. Add daily totals, recent meals, edit/delete, loading and empty states. Make the primary flow comfortable on a phone.
9. Add GET /api/health. It must return a small non-secret JSON response and a non-200 status when the app cannot reach its database. Do not require authentication for this endpoint.
10. Add a production Dockerfile with an efficient multi-stage build, a non-root runtime user where practical, a small runtime image and a startup path that applies safe migrations before starting the app.
11. Add .env.example, .gitignore rules, a concise README and deployment notes covering the exact data volume path, internal port, health path, migration command and required environment-variable names.

VERIFY BEFORE DEPLOYING
1. Add focused tests for authentication boundaries, health response, database persistence logic, model-output validation and the main mobile flow. Do not call the paid Replicate API in tests.
2. Run formatting, lint, TypeScript checking, tests and the production build. Fix every relevant failure.
3. Inspect at 320px, a common iPhone width, tablet and desktop. Fix overflow, contrast, focus order, touch targets and code or error text that breaks the layout.
4. Create or reuse the private GitHub repository GITHUB_OWNER/REPO_NAME. Commit logical changes and push the finished branch. Preserve concurrent work and do not force-push over other changes.

DEPLOY WITH COOLIFY
1. Reuse the existing Coolify project/application when one already matches this repository and domain. Otherwise create one application connected to the private GitHub repository, using the GitHub App or a read-only deploy key.
2. Configure the production branch, Dockerfile build, internal port, DOMAIN, /api/health, and one replica.
3. Create a persistent volume whose container destination exactly matches the SQLite data directory. Confirm the database file is written there, not inside the replaceable container filesystem.
4. Add the required production environment variables from the named secret files without displaying their values. Mark sensitive values as secrets.
5. Make migrations run safely once during startup or as a controlled pre-deploy command. Never run two SQLite replicas against the same file.
6. Trigger the deployment. Watch build and runtime logs without exposing secrets. If the small host runs out of memory during builds, reduce build load, use a more efficient Docker build or add safe headroom/swap, then retry.
7. Wait for DNS and HTTPS, then verify the exact live URL.

LIVE ACCEPTANCE CHECKS
- DOMAIN serves valid HTTPS.
- An unauthenticated visitor cannot see app data or call protected APIs.
- Login and logout work, and the session cookie has secure production settings.
- /api/health returns success without leaking configuration.
- A test meal can be estimated through a server-side Replicate call, edited and saved.
- The saved meal still exists after a redeploy/restart.
- The interface works at 320px and a common iPhone width.
- The GitHub repository is private, one app replica is running, the SQLite volume is mounted, and a backup method is documented.
- No real secret exists in source, git history, screenshots, prompts or logs.

Finish by reporting the live URL, deployed commit, checks run, Coolify resource used, volume destination, health result and any secret files I should now delete. Never include a secret value in the report.

Use the existing Coolify instance and deploy the existing private GitHub repository. Do not create duplicate projects, applications or repositories.

- Coolify URL: COOLIFY_URL
- Coolify API token file: COOLIFY_TOKEN_FILE_PATH
- Server/project/environment IDs if known: COOLIFY_IDS_OR_UNKNOWN
- GitHub repository and branch: GITHUB_OWNER/REPO_NAME, BRANCH
- Production domain: DOMAIN
- Required environment variable names: ENV_VAR_NAMES_ONLY
- Secret file paths: SECRET_FILE_PATHS
- SQLite container directory: SQLITE_DATA_DIRECTORY
- Health endpoint: /api/health

Read secrets only from the exact files above. Never print, echo, log, screenshot, commit or paste their contents into chat. Use the narrowest Coolify token permissions that can complete the job. Inspect existing resources first, configure one replica and a persistent volume, set encrypted environment variables, deploy, wait for healthy HTTPS, verify auth and persistence across one redeploy, then report IDs and results without secret values.

Deploy the current app update all the way to production.

App folder: LOCAL_PATH
Repository: GITHUB_OWNER/REPO_NAME
Domain: DOMAIN
Coolify URL: COOLIFY_URL
Coolify token file: COOLIFY_TOKEN_FILE_PATH

Inspect the existing branch, GitHub repository and Coolify resource first. Reuse them; do not create duplicates. Preserve concurrent changes. Read the token file only when needed and never print, log, commit or paste its contents.

Use current official docs for any API that may have changed. Run lint, typecheck, tests and the production build. Confirm migrations are safe, SQLite remains on its persistent volume with exactly one replica, and secrets stay server-side. Commit and push the finished update, trigger or wait for the existing Coolify deployment, then verify HTTPS, auth, /api/health, the changed feature and persistence on DOMAIN. Do not stop at a plan, local build or successful push. Report the live commit and verification results without secret values.