Building the transferify.eu platform on AWS with Terramate

What was the situation?

A file-transfer product that sells under one brand per country (a Romanian brand, a German brand, a European one) needed a platform that treated a new market as configuration rather than a project. Each brand has its own domain, certificate, locale tree and email identity, but the application, the data and the team are the same. The platform also had to be operable by a very small team, which rules out anything that needs a person to remember a manual step.

How is the edge organised?

One CloudFront distribution serves every brand from one S3 bucket. The brand list is a single committed file; from it the Terraform derives the aliases, the certificate names, the DNS records, the CORS origins and the routing table that a CloudFront Function uses to map each host to its locale tree. Adding a market is one entry in that file. A redirect-only entry lets a domain answer TLS and send visitors to the current main brand, which is how the product moved its primary domain without an outage. The function’s routing table is unit-tested in Node, and its size is checked against CloudFront’s quota at plan time.

How are services and data run?

The API runs on ECS behind a load balancer shared between environments, so a development environment costs a target group rather than a second load balancer. Transfer data lives in Cloudflare R2, with the storage module switchable to S3. The production database is private; engineers reach it over a WireGuard hub rather than a bastion with a public port. Alarms cover the things that have actually failed, renotify until acknowledged, and are proven by a guard that fails a pull request if an alarm could fall silent.

How is the Terraform kept safe?

Everything is a Terramate stack selected by tag and run through one wrapper that refuses to run against nothing. Every input is committed: constants of the account live in globals, toggles default to the live value, and secrets are never variables; providers read them from the environment at plan time, sourced from the cloud’s parameter store. A sweep fails any stack whose behaviour depends on a file git does not track. The rule exists because of an incident: a toggle whose live value lived only in a gitignored file once made a fresh clone plan the destruction of live storage. Guards run on every pull request (formatting, validation, module tests, policy assertions) and one required check decides the merge.

What would we do again?

All of it, in the same order: the brand list as the one source of configuration, the edge function tested as code, the wrapper that cannot plan nothing, and the committed-inputs rule enforced by a sweep rather than a document. The same conventions now run Kitecorp’s own site, and they are the basis of the infrastructure as code and CI/CD and GitOps engagements.