🗼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

1. Infrastructure Patterns - What FormSG needs from your platform

2. Migration Approach - How to implement it step by step

3. 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.

What We Know

✅ The architecture uses standard patterns (containers, MongoDB, S3-compatible storage) ✅ Other governments have likely deployed on different clouds 📋 This guide provides architectural patterns for adaptation to your platform

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

Container Service

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/forms endpoint

• Auto-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

Storage & Database

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

Load Balancing & Network

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

Monitoring & Logging

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

Serverless Functions

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

1

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:

• Container platform can run Docker images

• Object storage passes S3 compatibility tests

• Load balancer routes traffic correctly

• Basic monitoring collects metrics

2

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:

• Database accepts MongoDB connections

• Application can read/write form data

• Backup and restore procedures work

• Performance meets requirements

3

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:

• Admin login OTPs delivered via email

• Form submissions trigger notifications

• Identity authentication works

• All integrations handle errors gracefully

4

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:

• All traffic encrypted in transit

• Secrets properly managed and rotated

• Access controls enforced

• Security monitoring operational

💡 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.