# Infrastructure Guidance

### FormSG Architecture Reference

Understanding FormSG's complete architecture helps you plan which components to migrate and which to replace:

<figure><img src="https://3225095994-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFiAVh1Ff3KUiYxMAZuJG%2Fuploads%2FsCNmoCABlx9kYtFUc3UG%2Fimage.png?alt=media&#x26;token=d9ebf561-8a54-44c9-b2df-bfa7e6fae50c" alt=""><figcaption></figcaption></figure>

### When to Use This Guide

Use the guides at [deployment](https://international.open.gov.sg/self-hosting/formsg/deployment "mention") 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.

{% hint style="info" %}
**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
{% endhint %}

### 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

{% tabs %}
{% tab title="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
  {% endtab %}

{% tab title="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
  {% endtab %}

{% tab title="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
  {% endtab %}

{% tab title="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
  {% endtab %}

{% tab title="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
  {% endtab %}
  {% endtabs %}

### 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

{% stepper %}
{% step %}
**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
  {% endstep %}

{% step %}
**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
  {% endstep %}

{% step %}
**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
  {% endstep %}

{% step %}
**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
  {% endstep %}
  {% endstepper %}

{% hint style="success" %}
**💡 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.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://international.open.gov.sg/self-hosting/formsg/infrastructure-guidance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.