Back to login
Security & Infrastructure

Platform Architecture

Maica Apps is built on enterprise-grade AWS infrastructure, designed specifically for Salesforce users. Here is exactly how your data is stored, protected, and kept available.

Data stays in Sydney
Encrypted at rest and in transit
No passwords stored
Automatic failover
AWS Sydney
Data residency
Multi-AZ
Database availability
TLS 1.2+
Encryption in transit
AES-256
Encryption at rest
Hosting & Infrastructure
Your data lives on Amazon Web Services in Sydney — the same cloud used by Australian banks and government agencies.
Technical detail

Containerised Next.js application running on Amazon ECS (EC2-backed). Application Load Balancer (ALB) terminates TLS and routes traffic. Database: Amazon Aurora PostgreSQL 15 in a Multi-AZ cluster (writer + reader endpoints) in ap-southeast-2. Static uploads stored in Amazon S3 with server-side encryption. All compute and storage stays within the AWS ap-southeast-2 (Sydney) region — no cross-region replication.

AWS ap-southeast-2 (Sydney)Amazon ECSAurora PostgreSQLAmazon S3
Authentication & Sessions
You log in with a one-time magic link sent to your email, or via Google or GitHub OAuth. No passwords to leak.
Technical detail

NextAuth v5 with a JWT session strategy. Sessions are stored in signed, HttpOnly, Secure cookies — never in localStorage or sessionStorage. Magic link tokens are single-use, expire in 15 minutes, and are bcrypt-hashed before storage. OAuth flows (Google, GitHub) use provider-issued tokens; Maica never stores your OAuth password or refresh token. Middleware validates the JWT on every protected request at the Edge before the request reaches a server.

Magic link (email)Google OAuthJWT + HttpOnly cookiesEdge middleware
Access Control
Only invited email addresses or domains can log in. Workspace owners control who sees what.
Technical detail

Access is gated by an AllowedIdentity table — admins explicitly allowlist individual emails or entire domains. Super-admins are defined via the ADMIN_EMAILS environment variable and bypass the allowlist. All API routes are protected by session middleware; admin endpoints additionally verify the requester's email against the super-admin list. Workspace-level isolation: every user and team operates within a workspace boundary that is enforced on every DB query.

Email/domain allowlistAdmin roleWorkspace isolationRoute-level auth
Data Security
All stored data is encrypted. Secret credentials are never in source code or environment files — they live in a secure vault.
Technical detail

Aurora PostgreSQL storage is encrypted at rest with AWS-managed KMS keys. S3 buckets use SSE-S3 encryption. All database credentials, OAuth client secrets, and API keys are stored in AWS Secrets Manager and injected into the container at runtime — they are never committed to source code or baked into the Docker image. Database connections enforce TLS in transit (rejectUnauthorized: false for RDS certificate rotation compatibility). Sequelize parameterised queries prevent SQL injection throughout.

KMS encryption at restTLS in transitAWS Secrets ManagerParameterised queries
Availability & Redundancy
The database automatically fails over to a standby replica if there is a hardware problem. Deployments are rolling — no downtime.
Technical detail

Aurora Multi-AZ provides automatic failover (typically under 30 seconds) to a standby replica in a separate Availability Zone. The ALB performs continuous health checks against /api/health; unhealthy targets are removed from rotation automatically. ECS rolling deployments ensure the old container keeps serving traffic until the new version passes health checks. Application tables are managed by Sequelize alter-sync — new columns are added non-destructively without dropping existing data.

Multi-AZ Aurora failoverALB health checksRolling ECS deploys
Email & Communications
Outbound emails — magic links, document invitations — are sent via Amazon SES with optional custom domain branding.
Technical detail

All transactional email is delivered through Amazon SES. Custom sending domains are verified using a TXT identity record plus three DKIM CNAME records, enabling full DKIM/SPF signing. Daily send quotas are enforced per workspace; accounts that exceed thresholds or trigger bounce/complaint events are automatically suspended with an explanatory reason stored in the database. Reply-to and From addresses are configurable per workspace but must use the verified sending domain.

Amazon SESDKIM + SPF signingCustom sending domainsPer-workspace quotas
Salesforce Integration
Connecting Salesforce is optional. If you do, your credentials are stored only for your account and are never shared.
Technical detail

Salesforce connections use the OAuth 2.0 PKCE flow — Maica receives an access token and refresh token that are stored encrypted at rest per user (SFConnection model). Maica never asks for or stores your Salesforce username or password. Token refresh is handled transparently in the background. API calls to Salesforce are proxied server-side; the token is never exposed to the browser. Connections are per-user and scoped to the authenticated session.

OAuth 2.0 PKCEPer-user token storageServer-side proxyNo password stored
Application Security
Standard web security controls are in place to protect against the most common attack types.
Technical detail

HTTPS enforced at the ALB with TLS 1.2+; HTTP is not exposed. CSRF protection via SameSite cookie policy and origin validation. All user-controlled inputs are validated server-side before DB writes. Salesforce and form submission endpoints apply rate limiting. Public form endpoints (/f/, /api/submissions) are separated from authenticated endpoints in middleware to minimise attack surface. Dependency updates are reviewed before deployment; Docker base images use node:20-alpine (minimal attack surface).

TLS 1.2+SameSite cookiesServer-side validationRate limiting
Documents & PDF Generation
Forms, e-signature envelopes, and generated PDFs are produced entirely on our servers. No third-party document services see your data.
Technical detail

PDF generation uses Puppeteer with a server-installed Chromium binary plus pdf-lib for post-processing. All rendering happens inside the ECS container in ap-southeast-2. Generated documents are stored in the workspace S3 bucket (encrypted at rest). E-signature envelopes track recipient status in the database; signing tokens are single-use and time-limited. No document content is sent to external rendering APIs or third-party cloud services.

Server-side Puppeteerpdf-lib post-processingS3 encrypted storageSingle-use signing tokens
Data Sovereignty
Your data does not leave Australia. Everything is stored and processed in Sydney.
Technical detail

All services — ECS cluster, Aurora cluster, S3 buckets, SES sending, Secrets Manager, and ALB — are provisioned exclusively in AWS ap-southeast-2 (Sydney). No cross-region replication is configured. Backups created by Aurora automated backup also remain in ap-southeast-2. This design satisfies Australian data residency requirements relevant to NDIS and Aged Care providers under the Privacy Act 1988 and relevant NDIS Practice Standards.

AWS Sydney (ap-southeast-2)No cross-region replicationPrivacy Act 1988 alignment