Your entire installation
GrigTasks consists of an API, PostgreSQL, file storage and a separate mail service. A ready-made web interface can be included, or you can deploy only the API.
Components
| Component | Responsibility |
|---|---|
| API | Access, projects, tasks, transitions and consistent authorization |
| PostgreSQL | Team data, action history and the email queue |
| File storage | Task attachments |
| Mail service | Processing the queue through your chosen transport |
| Web interface | Browser access and the local action queue |
Manage the installation
The grig-tasks command provides a terminal menu for service status, starting and stopping services, logs, email configuration and backups. Direct subcommands and machine-readable output are available for automation.
The API and mail service report separate states. The mail service can be restarted independently. Exact commands will be published after release verification.
Email
The owner chooses local delivery, external SMTP or a custom driver. Messages are stored in the database before a separate service processes them.
A normal restart resumes delivery. If job state is lost after a long outage or restore, the message shows a visible error and an operator can retry it.
If an external transport accepted a message but its confirmation was lost, retrying can deliver a duplicate email. Protection against duplicate tasks is not a guarantee of exactly-once email delivery.
Backups
A backup must include the database, files and required installation configuration. Keep copies separately and test recovery on an isolated installation.
Restoring creates a new synchronization scope. Old client actions need reconciliation. GrigDesk collections remain in their previous scope and do not migrate automatically.
Team responsibilities
Your team manages HTTPS, server access, updates, email and backups. Before production use, verify the full journey: invitation, first task, review and backup recovery.
Next: prepare your installation.