Skip to content
back to the quest log
FILCA infrastructure diagram — production, shop and testing environments behind a shared load balancer
rare⎈ infrastructureinternal

FILCA

Three environments, one pipeline

Production, shop and testing environments behind one load balancer, with builds pushed by GitHub Actions and alerts landing in Discord.

role
Infrastructure engineer
org
Estella Studio
when
2025

What it is

A compact three-environment topology — FILCA production, FILCA shop and a testing tier — all served through Sora, the load balancer and exit node, with authentication in front and db-central behind.

Developers push, GitHub Actions builds the Docker image, acheron-server watches and rolls it forward. Sellers and end users hit the same edge; the team hears about it in Discord.

where the effort went

  • Delivery82
  • Reliability70
  • Security65
  • Automation78

the numbers

Environments
3
CI
GitHub Actions
Alerting
Discord
Edge
Sora

built with

  • Docker
  • GitHub Actions
  • NGINX
  • PostgreSQL
  • Linux

delivery record

What I made

FILCA needed production, seller, and test environments that could ship from one repeatable pipeline without giving each surface a separate operational model.

  • 01

    Production, seller, and testing deployment tiers

  • 02

    Shared load-balancer and authentication edge

  • 03

    Docker image builds driven by GitHub Actions

  • 04

    Automated rollout through the application host

  • 05

    Central PostgreSQL service and Discord deployment feedback

Hard problems

The constraints mattered as much as the finished interface.

01field note

Separating environments without duplicating operations

problem
Three application surfaces need isolation but duplicated pipelines would drift and make releases unpredictable.
response
The topology keeps environment-specific services behind one edge and one image pipeline with explicit deployment targets.
02field note

Closing the feedback loop

problem
A successful image build does not prove that the intended environment actually rolled forward.
response
Host-side rollout status and alerts land in Discord so the team sees deployment completion from the runtime side.

The rack

Named machines, as they appear in the diagram. Yes, they are all named after something.

  • SoraLoad balancer · exit node
  • acheron-serverBuild & deploy host
  • db-centralDatabase

Architecture

Drawn as it was built. Open it full size — the labels are the interesting part.

after shipping

What stayed with me

  • Environment separation should change configuration and boundaries, not create three unrelated delivery systems.

  • Deployment feedback is most useful when it confirms the running target, not only the CI job.