59 lines
3.3 KiB
Markdown
59 lines
3.3 KiB
Markdown
# Documenso on AWS
|
|
|
|
This Terraform stack deploys Documenso to AWS in `ca-central-1` using:
|
|
|
|
- ECS Fargate for the application tier
|
|
- RDS PostgreSQL for the database tier
|
|
- S3 for document uploads and signed PDFs
|
|
- Application Load Balancer with ACM-managed TLS
|
|
- Route53 DNS for `esignature.imex.online`
|
|
- Optional SES domain identity and DKIM management for outbound email
|
|
- Secrets Manager for generated application secrets, SMTP credentials, and the optional Documenso signing certificate
|
|
- AWS WAF with a basic managed rule set and rate limiting
|
|
- CloudWatch alarms for ALB, ECS, and RDS health indicators
|
|
|
|
## Why this shape
|
|
|
|
This is the most practical fit for your Docker Compose workload if you want a balance of cost efficiency, managed operations, and scaling:
|
|
|
|
- Fargate gives you horizontal scaling without managing EC2 hosts.
|
|
- RDS PostgreSQL is simpler and cheaper than Aurora for a single Documenso workload.
|
|
- S3-backed uploads are better for production scale and keep document growth out of PostgreSQL.
|
|
- The database stays private; the ALB is public.
|
|
- The ECS tasks run in public subnets to avoid a NAT gateway charge. Inbound access is still restricted to the ALB security group.
|
|
- HTTPS is terminated by the ALB using ACM. The Documenso self-signed `.p12` certificate is separate and is used for document signing, not browser TLS.
|
|
|
|
## Files
|
|
|
|
- `main.tf`: core infrastructure
|
|
- `variables.tf`: configurable inputs
|
|
- `outputs.tf`: useful deployment outputs
|
|
- `terraform.tfvars.example`: example input values
|
|
|
|
## Assumptions built into this stack
|
|
|
|
1. Your DNS for `imex.online` is hosted in Route53.
|
|
2. You want Multi-AZ RDS enabled from the start for database availability.
|
|
3. You are comfortable starting with `documenso/documenso:latest`. For repeatable deployments, pin a version or digest after your first rollout.
|
|
4. You will provide SES SMTP credentials. Terraform does not derive SMTP passwords for you.
|
|
5. SES identity and DKIM might already be managed outside this stack. By default, this Terraform does not attempt to create them.
|
|
6. You will provide a base64-encoded PKCS#12 signing certificate and passphrase if you want document signing enabled immediately. This stack injects those values through Secrets Manager instead of mounting a host file.
|
|
7. You are comfortable with Terraform creating a dedicated IAM user and access key for Documenso S3 uploads because Documenso documents explicit S3 credentials for the upload backend.
|
|
8. You want Terraform destroy protection enabled for both the database and the uploads bucket.
|
|
|
|
## Deploy
|
|
|
|
1. Copy `terraform.tfvars.example` to `terraform.tfvars` and fill in the SMTP values.
|
|
2. If you want Documenso signing enabled, add `signing_certificate_base64` and `signing_certificate_passphrase`.
|
|
3. Optionally set `upload_bucket_name` if you want a specific S3 bucket name.
|
|
4. Set `manage_ses_resources = true` only if you want this stack to own SES identity verification and DKIM records.
|
|
5. Run `terraform init`.
|
|
6. Run `terraform plan`.
|
|
7. Run `terraform apply`.
|
|
|
|
## Recommended first production adjustments
|
|
|
|
1. Pin the Documenso image to a tested version or digest.
|
|
2. Wire `alarm_actions` to an SNS topic, PagerDuty bridge, or your on-call system so alarms notify someone.
|
|
3. Expand the WAF rule set if you need more aggressive filtering later.
|
|
4. Add CloudWatch alarms on ECS 5xx errors, ALB target health, and RDS CPU/storage. |