System Architecture

Two deployment models — Shared (Heroku + S3) and dedicated Enterprise (AWS); actors, data flows and controls

The SSM.ro Ecosystem

The SSM.ro platform connects all the actors involved in an organization's workplace safety (SSM) management:

Actor	Platform role	Actions on the platform
Employer	Super User	Manages the commercial account and organizations; drafts documents; receives notifications and reports
H.R.	User	Manages personnel documentation; integration via API
Internal SSM Service	User	Drafts and monitors internal SSM documents
External SSM Service	User	Drafts and monitors external SSM documents (service-provider companies)
Workplace Supervisor	Employee	Reviews and signs documents; does not manage
Employee	Employee	Receives training, signs documents, receives notifications
Audit/Control	— (read-only)	Control access to documentation (read-only)
Beneficiary's Electronic Archive	—	Daily export of signed documents via API
Electronic Signature Provider	External service	Used by the platform for remote electronic signing of digital documents

Deployment Models

SSM.ro is available in two deployment models with distinct technical architectures: Shared Model (SaaS) and Enterprise Model (Dedicated).

Detailed comparison

The complete comparison of the two models (infrastructure, authentication, data isolation, SLA) is on the canonical Deployment Models page. Below are the technical architecture details for each model.

Technical Architecture — Shared Model (SaaS)

Shared Model (SaaS)

This section describes the multi-tenant architecture on Heroku + AWS S3.

Client & Edge Layer

Users (browser/mobile)
    │ HTTPS only
    ▼
DNS (public resolver)
    │
    ▼
Heroku Router — TLS termination
    Certificate: Let's Encrypt (automatic renewal)
    TLS 1.2+, HSTS active

Application Platform (Heroku)

Component	Details
Web dynos	Web application, autoscaling; authentication: email + password; optional TOTP 2FA (code from an authenticator app or sent by email); per-organization OIDC SSO (optional or exclusive)
Worker Dyno	Asynchronous jobs: signing orchestration, notifications, daily archive export
Heroku Postgres	Main database; TLS in transit, encryption at rest; continuous PITR + daily snapshots (30-day retention); hosts customer activity logs (3 months)
Heroku Redis	Cache + asynchronous job queue; TLS in transit; private within the Heroku network

AWS Services (Shared Model)

The Shared Model uses AWS microservices for processing, storage and logging, within a shared infrastructure:

Service	Role
AWS S3 — Primary	Document content storage; versioning enabled; SSE; Block-public-access ON; lifecycle delete markers after 100 days
AWS S3 — CRR Replica	Cross-region replica; backup/DR only; no application reads/writes it directly
AWS API Gateway	Proxy for Lambda microservices; authentication, throttling, logging
AWS Lambda	Stateless microservice functions (IAM-scoped)
AWS CloudWatch Logs	Signing audit log (append-only, encrypted, 5-year retention)

Trusted External Providers

Provider	Role
Postmark	Transactional email (notifications, OTP, password reset, system alerts); HTTPS API, dedicated server token
Electronic Signature Provider	Qualified electronic signature provider (eIDAS QTSP); typically receives only the document hash and returns the digital signature; certain providers require the full document to be transmitted for signing; HTTPS authentication via mTLS or API token
New Relic	Live logs + APM; alerts on error rates; SaaS
Sentry	Runtime exception monitoring; alert email; SaaS
OIDC IdP (per organization)	Optional or exclusive SSO, per organization; external, managed by the customer

Build & Release Pipeline

GitHub (main branch, mandatory PR review)
    │ webhook on merge
    ▼
Heroku Build (slug compile, buildpack)
    │
    ▼
Heroku Release (rolling restart of web + worker dynos)
    │
    ▼
Versioned releases with one-click rollback

Technical Architecture — Enterprise Model (Dedicated)

Enterprise Model (Dedicated)

This section describes the architecture with dedicated AWS infrastructure per customer.

General Characteristics

Dedicated AWS infrastructure per customer — servers and resources are not shared with other customers
Customer's own domain clientdomain.ext (e.g. ssm-companie.ro) — not a subdomain on *.appssm.ro; the installation may host one or more organizations on subdomains, with separate data
Full white-label — own logo, platform contact details, customized email messages, document headers; the platform appears under the customer's visual identity
SSO via SAML — a single configuration for the customer's primary domain; email/password authentication remains available for external accounts; access to organizations is managed internally through roles
99.9% SLA guaranteed monthly availability; maintenance windows negotiated contractually

AWS Services (Enterprise Model)

The Enterprise Model may include, per contractual specifications:

Service	Role
AWS S3	Document content storage (primary + CRR replica)
AWS ECS	Containers for the application and asynchronous jobs
AWS API Gateway	API routes; request authentication/authorization; throttling
AWS Lambda	Stateless processing functions; IAM-scoped
AWS SES	Transactional email (notifications, OTP, system alerts)
AWS CloudWatch Logs	Signing audit log (5-year retention; append-only; encrypted)

Data Flows — Shared Model

#	Flow
1	Employees ↔ SSM.ro Application: authentication, document viewing, signing
2	Administrators ↔ SSM.ro Application: authentication, data entry, document upload
3	Application ↔ Heroku Postgres: users, employees, document metadata, activity logs (3 months)
4	Application ↔ AWS S3 (primary): document content (upload, retrieval)
5	Application → Electronic Signature Provider: typically only the document hash; full document if the provider requires it to be transmitted in full
6	Electronic Signature Provider → Application: digital signature returned
7	Application → Postmark: transactional emails (notifications, OTP, system alerts)
8	Application → Tenant's external archive: daily export of documents to the destination chosen by the tenant
9	S3 (primary) → S3 (CRR Replica): managed replication for backup/DR
10	Postgres → Heroku Backups: continuous PITR + daily snapshots, 30-day retention
11	Application → New Relic / Sentry: live application logs and error events
12	Application → AWS CloudWatch Logs: audit event generated on every electronic signing

Signing Flow

Standard case (hash-based, privacy-preserving):

The document is hashed locally within the application
Only the hash is sent to the electronic signature provider via HTTPS (mTLS or API token)
The provider returns the digital signature (the signed hash)
The signature is embedded into the PDF document on the platform

Case where the provider requires the full document:

Certain electronic signature providers require the full document (not just the hash) to be transmitted in order to perform the signing. In this case, the document content is transmitted to that provider and leaves the platform.

Cross-Cutting Controls

These controls apply to both models:

All external traffic: HTTPS/TLS 1.2+ — certificates with automatic renewal
Access to AWS services: least-privilege IAM credentials; secrets are not included in the source code
Encryption at rest: database, cache, S3 (primary + replica)
Backup & DR: database PITR + daily snapshots; AWS S3 versioning + cross-region replication; release rollback

System Architecture

On this page