Feat/incremental message sync

[dpolishuk]

This pull request introduces a comprehensive, production-ready deployment setup for the project, along with a technical implementation plan for incremental message sync. The most significant changes are the addition of a robust deploy.sh script for interactive and reliable Docker-based deployments, a new docker-compose.yml for orchestrating services, and documentation for implementing incremental sync in the messages API. Additionally, the Docker build now includes the Prisma schema directory.

Deployment & Infrastructure

• Added a full-featured deploy.sh script that interactively configures environment variables, manages Docker Compose services, handles database initialization/reset, configures HTTPS with Caddy, and verifies service health for easy local or production deployment.
• Introduced a new docker-compose.yml defining services for the app, PostgreSQL (with initialization), Redis, Minio (S3-compatible storage), and Caddy, including healthchecks, dependencies, and persistent volumes for robust orchestration.
• Updated the Dockerfile to copy the prisma directory into the image, ensuring database schema access at runtime.

Documentation & Planning

• Added a detailed implementation plan (docs/plans/2025-01-01-incremental-message-sync-implementation.md) for supporting incremental message synchronization in the API, including query parameter handling, Prisma indexing, and manual testing steps.

[Copilot]

Pull request overview

This pull request introduces production deployment infrastructure and documentation for an incremental message synchronization feature. The changes include a comprehensive deployment script for Docker-based orchestration, service configuration, and detailed technical planning documents for implementing efficient message syncing.

• Adds automated deployment tooling with interactive configuration for domains, passwords, and data handling
• Introduces Docker Compose orchestration for the application stack with PostgreSQL, Redis, MinIO, and optional Caddy
• Documents incremental sync architecture to reduce message fetch latency from seconds to milliseconds

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 14 comments.

Show a summary per file

File	Description
deploy.sh	Interactive deployment script handling Docker services, database setup, Caddy configuration, and health verification
docker-compose.yml	Orchestrates app, PostgreSQL, Redis, MinIO, and related initialization services with healthchecks and volumes
Dockerfile	Adds prisma directory to runtime image for database schema access
docs/plans/2026-01-01-deploy-script-design.md	Design documentation for the deployment script architecture and workflow
docs/plans/2025-01-01-message-sync-latency-design.md	Technical design for reducing message sync latency via incremental fetching
docs/plans/2025-01-01-incremental-message-sync-implementation.md	Step-by-step implementation plan for the incremental sync feature

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The default password "postgres" is hardcoded in the DATABASE_URL. This means even if the postgres service is configured with a different password through POSTGRES_PASSWORD, the app will still try to connect with "postgres" as the password. This configuration should reference the environment variable or be consistent with the password setup.

[Copilot]

The hardcoded credentials "minioadmin/minioadmin" for S3_ACCESS_KEY and S3_SECRET_KEY are default MinIO credentials. These should be configurable and generated securely, similar to the PostgreSQL password handling in the deploy script.

[Copilot]

The PostgreSQL password stored in the .env file is in plaintext. While the file is gitignored, consider adding a note in the documentation about securing this file with appropriate file permissions (e.g., chmod 600 .env) to prevent unauthorized access on shared systems.

Suggested change

	Credentials stored in `.env` file (gitignored).
	Credentials stored in `.env` file (gitignored); ensure it is protected with restrictive permissions (for example, `chmod 600 .env`) to prevent unauthorized access on shared systems.

[Copilot]

The newestTimestamp calculation uses updatedAt while oldestTimestamp uses createdAt. This inconsistency could cause issues when the client uses newestTimestamp for the next updatedAfter query, as it's comparing different timestamp fields. Both should likely use the same field (probably updatedAt for consistency with the incremental sync feature).

Suggested change

	oldestTimestamp: Math.min(...messages.map(m => m.createdAt.getTime())),
	oldestTimestamp: Math.min(...messages.map(m => m.updatedAt.getTime())),

[Copilot]

The hardcoded value "your-super-secret-key-change-in-production" for HANDY_MASTER_SECRET is insecure. This secret is used directly in the docker-compose file without any prompting or generation during deployment. Anyone with access to the repository can see this default value, creating a significant security vulnerability.

Suggested change

	- HANDY_MASTER_SECRET=your-super-secret-key-change-in-production
	- HANDY_MASTER_SECRET=${HANDY_MASTER_SECRET:?HANDY_MASTER_SECRET not set}

[Copilot]

The PostgreSQL password is interpolated directly into the shell command without proper escaping. If the password contains special characters (like $, `, ", ), the ALTER USER command could fail or behave unexpectedly. Consider using proper quoting or escaping for the password value.

Suggested change

	$COMPOSE_CMD exec -T postgres psql -U postgres -c "ALTER USER postgres WITH PASSWORD '$POSTGRES_PASSWORD';" > /dev/null
	ESCAPED_POSTGRES_PASSWORD=$(printf "%s" "$POSTGRES_PASSWORD" | sed "s/'/''/g")
	$COMPOSE_CMD exec -T postgres psql -U postgres -c "ALTER USER postgres WITH PASSWORD '${ESCAPED_POSTGRES_PASSWORD}';" > /dev/null

[Copilot]

The querystring schema field should be marked as optional at the schema level using .optional(), but the inner object fields (updatedAfter, before, limit) are already optional. This creates a discrepancy where the entire querystring object is required but its contents are optional. Consider making the querystring itself optional or ensuring all fields have appropriate defaults.

Suggested change

	updatedAfter: z.coerce.number().int().min(0).optional(),
	before: z.coerce.number().int().min(0).optional(),
	limit: z.coerce.number().int().min(1).max(150).default(150)
	})
	updatedAfter: z.coerce.number().int().min(0),
	before: z.coerce.number().int().min(0),
	limit: z.coerce.number().int().min(1).max(150)
	}).partial().default({ limit: 150 }).optional()

[Copilot]

The S3_PUBLIC_URL uses "localhost" which will not work correctly in production or when accessed from outside the Docker network. This should be configurable based on the domain provided during deployment, similar to how the Caddy configuration uses the domain variable.

Suggested change

	- S3_PUBLIC_URL=http://localhost:9000/happy
	- S3_PUBLIC_URL=http://${DOMAIN:-localhost}:9000/happy

[Copilot]

Setting DANGEROUSLY_LOG_TO_SERVER_FOR_AI_AUTO_DEBUGGING to true in a production deployment configuration is concerning. The variable name itself indicates this should not be enabled in production. This should either be removed or set to false by default, with an option to enable it only for development environments.

Suggested change

	- DANGEROUSLY_LOG_TO_SERVER_FOR_AI_AUTO_DEBUGGING=true
	- DANGEROUSLY_LOG_TO_SERVER_FOR_AI_AUTO_DEBUGGING=false

[Copilot]

The same default MinIO credentials "minioadmin/minioadmin" are used here. These should match whatever credentials are configured for the app service and should be securely generated rather than using defaults.