🗼Infrastructure Guidance
This document provides proven deployment patterns from FormSG production experience, simplified for government teams to adapt to their specific environments.
FormSG Architecture Reference
Understanding FormSG's complete architecture helps you plan which components to migrate and which to replace:
When to Use This Guide
Use the guides at Deployment wherever possible, this guide covers
Other cloud deployment not covered like GCP, Azure, or other cloud environment
On-premise deployment
Understanding FormSG architecture for platform adaptation
What This Guide Covers
Infrastructure Patterns - What FormSG needs from your platform
Migration Approach - How to implement it step by step
Getting Started - Next steps for your deployment
Platform Context
FormSG was architected for AWS and that's where we have production experience. While the architecture is cloud-agnostic in theory, we haven't tested other cloud deployments.
Infrastructure Patterns
This section covers FormSG's infrastructure requirements in a cloud-agnostic way that you can adapt to your specific tools and environments.
Core Deployment Patterns
What it does: Runs FormSG application with auto-scaling and health monitoring
Requirements:
Container image: Build from FormSG source or use your registry
Port: 5000 (internal application port)
Health check:
/api/v3/admin/formsendpointAuto-scaling: 2-10 instances based on CPU utilization (70% threshold)
Environment variables: NODE_ENV, DB_HOST, SESSION_SECRET
Load balancer: For high availability and traffic distribution
Adapt for your environment:
Adjust scaling parameters based on expected load
Configure environment variables in your secrets management system
What it does: Provides secure, scalable storage for forms, attachments, and application data
Database (MongoDB-compatible):
Features needed: transactions, TTL indexes, aggregation pipelines
Connection: Standard MongoDB connection string
Backup and disaster recovery procedures
Object Storage (S3-compatible):
Three buckets: attachments, images, static assets
Features needed: presigned URLs, lifecycle policies, server-side encryption
API compatibility with AWS S3
Session Storage:
Redis-compatible or database-backed sessions
24-hour TTL for user sessions
Encryption at rest and in transit
Adapt for your environment:
Choose managed database service vs. self-hosted based on your policies
Set up backup procedures according to your retention requirements
Implement encryption standards required by your compliance framework
What it does: Securely exposes FormSG to users while protecting backend services
Load Balancer:
HTTPS listener on port 443 with SSL certificate
HTTP to HTTPS redirect on port 80
Health checks to application containers
DDoS protection and rate limiting
Network Security:
Public subnets: Load balancer only
Private subnets: Application containers and database
Security rules: Load balancer → App (port 5000), App → Database (port 27017)
Web Application Firewall (WAF) for additional security
SSL/TLS:
Government-approved SSL certificates
TLS termination at load balancer
Encrypted traffic between all components
Adapt for your environment:
Configure WAF rules based on your security requirements
Adjust network segmentation for your compliance needs
What it does: Provides visibility into application performance, security events, and operational health
Infrastructure Metrics:
Container CPU and memory usage
Application response time and error rates
Database connection counts and performance
Failed authentication attempts
Alerting Thresholds:
High CPU and memory usage
High error rates and failed health checks
Database connectivity issues
Log Collection:
Application logs (errors, warnings, info)
Access logs (user requests and responses)
Security events (login attempts, permission changes)
Audit trail (admin actions, form modifications)
Adapt for your environment:
Set up log retention according to your compliance requirements
Implement audit logging as required by your security policies
What it does: Provides on-demand virus scanning for file uploads and other serverless processing tasks
Requirements:
Function runtime: Node.js-compatible serverless platform
Memory allocation: 512MB minimum for virus scanning operations
Triggers: S3 upload events
Dependencies: ClamAV or equivalent virus scanning engine
Network access: Download virus definitions and communicate with object storage
File Processing:
Virus scanning for form attachments
Adapt for your environment:
Choose managed functions (Azure Functions, Google Cloud Functions) or container-based serverless
Configure appropriate memory and timeout limits for your file sizes
Set up virus definition updates according to your security policies
Migration Approach
FormSG uses standard technologies (Docker, MongoDB, S3-compatible storage, SMTP) that exist on all major clouds:
AWS ECS → Any container service
AWS S3 → Any object storage with S3 API
MongoDB Atlas → Any MongoDB-compatible database
AWS SES → Any SMTP service
Migration Phases and Validation
Phase 1: Infrastructure Foundation
Objective: Establish core infrastructure components
Activities:
Set up container orchestration platform
Deploy object storage solution
Configure networking and load balancing
Establish monitoring and logging
Validation:
Phase 2: Data Services
Objective: Migrate database and configure data persistence
Activities:
Deploy MongoDB-compatible database
Configure connection strings and authentication
Set up backup and disaster recovery
Test data migration procedures
Validation:
Phase 3: Application Services
Objective: Configure external service integrations
Activities:
Configure email service integration
Set up SMS service (if required)
Configure identity provider integration
Test all communication channels
Validation:
Phase 4: Security and Compliance
Objective: Implement security controls and validate compliance
Activities:
Configure TLS/SSL certificates
Implement access controls and secrets management
Set up security monitoring and alerting
Conduct security testing
Validation:
💡 Success Tip: Start with a development environment to validate each component before migrating production workloads. This approach reduces risk and helps identify integration issues early.
Last updated
Was this helpful?