DEV and PROD topology, Docker Swarm, MariaDB, Redis, Nginx, private Docker registry, and the standard deployment flow for Hestino.
This page documents the standard server architecture for Hestino. It defines how DEV and PROD should be structured, which components run on the host, which components run inside Docker Swarm, and how application images are built, stored, and deployed.
```| Area | Decision |
|---|---|
| Operating System | Ubuntu 24.04 LTS |
| Application Runtime | Applications run as Docker Swarm services from versioned Docker images. |
| Database | MariaDB runs directly on the host server. |
| Cache | Redis runs as an internal Docker Swarm service with 1 replica. |
| Reverse Proxy | Nginx runs directly on the host server. |
| Image Registry | Docker images are stored in registry.dreamconsistency.com. |
| DEV Deployment | Automatic Jenkins deployment after image build. |
| PROD Deployment | Manual Jenkins deployment using the same image version already tested on DEV. |
Hestino is deployed as a multi-service system. Application services run inside Docker Swarm. Shared infrastructure services are split between the host and the Swarm depending on statefulness, operational simplicity, and access requirements.
The DEV environment is used for active testing, infrastructure validation, Docker Swarm deployment, and pre-PROD verification. It should stay close to the planned PROD architecture.
| Component | DEV Decision |
|---|---|
| Server | DEV-Hestino-16GB |
| Server Size | 8 vCPU, 16 GB RAM, 160 GB SSD |
| Domain | hestino.app currently points to the DEV server for temporary Coming Soon hosting. |
| Docker Mode | Single-node Docker Swarm manager. |
| MariaDB | Installed on host. Remote access allowed only from approved IP addresses. |
| Redis | Docker Swarm service, internal only, no public port. |
| Nginx | Installed on host. Handles public HTTP/HTTPS traffic and reverse proxy routing. |
| Firewall | UFW enabled. Public ports: 80 and 443. SSH and MariaDB restricted to approved IP addresses. |
PROD should use the same architecture as DEV, but with production domains, production secrets, production database, stricter deployment approval, and stronger backup discipline.
| Component | PROD Decision |
|---|---|
| Server Size | Planned: 8 vCPU, 16 GB RAM, 160 GB SSD |
| Docker Mode | Docker Swarm, initially single-node. |
| Deployment | Manual Jenkins deployment using the same image version already deployed and tested on DEV. |
| Database | Separate PROD MariaDB database on the PROD server. |
| Secrets | Separate PROD secrets. DEV secrets must never be reused for PROD. |
| Backups | MariaDB, Docker volumes, registry metadata, and application storage must have scheduled backups. |
Docker Swarm is used as the application orchestration layer. It runs Hestino services as replicated Docker services, manages restart policies, supports rolling updates, and gives a consistent deployment model between DEV and PROD.
| Service | Planned Replicas | Notes |
|---|---|---|
Hestino.Api |
2 | Main API service. Must be stateless. |
Hestino.Admin.Api |
2 | Admin API service. Must be stateless. |
Hestino.App |
2 | Public Razor Pages application. Must share ASP.NET Core Data Protection keys. |
Hestino.Admin.App |
1–2 | Angular 22 admin frontend. If served as static content, 1 replica is enough; 2 is acceptable for PROD mirror. |
Hestino.Worker |
1 | Central background worker. Keep 1 replica until locking and idempotency are implemented. |
Redis |
1 | Internal Swarm service. No public port. |
Nginx runs on the host server and acts as the public entry point. It handles HTTP/HTTPS, SSL certificates, redirects, static temporary pages, and reverse proxy routing to Docker Swarm services.
| Responsibility | Decision |
|---|---|
| Public HTTP | Port 80 open to the internet. |
| Public HTTPS | Port 443 open to the internet. |
| SSL | Managed through Certbot / Let's Encrypt. |
| Temporary Web | Coming Soon page can be served directly from host while application services are not ready. |
| Application Routing | Later routes traffic to Swarm-published service ports or internal reverse proxy services. |
MariaDB runs directly on the host server. It is not currently containerized because it is a stateful core dependency and should have explicit backup, restore, storage, and access-control management.
| Item | Current DEV Decision |
|---|---|
| Version | MariaDB 11.8 |
| Database | hestino_db |
| Application User | hestino_dev_user |
| Remote Access | Allowed only from approved IP addresses. |
| Root Access | Root remote login disabled. |
Redis runs as a Docker Swarm service and is available only inside the Hestino internal overlay network. It is not exposed through UFW or published as a public Docker port.
| Item | Current Decision |
|---|---|
| Runtime | Docker Swarm service |
| Replicas | 1 |
| External Access | Not allowed |
| Application Connection | redis:6379 from inside the Swarm network |
| Persistence | Redis data stored in Docker volume if append-only mode is enabled. |
Hestino Docker images are stored in the private Docker registry at
registry.dreamconsistency.com. Jenkins pushes images to the registry after a successful build.
DEV and PROD servers pull images from the registry during deployment.
latest. Every deployment must use a specific version tag.
Source code is not copied directly to DEV or PROD servers. Jenkins builds Docker images and pushes them to the private registry. Docker Swarm then deploys services from those versioned images.
| Path | Purpose |
|---|---|
/srv/dream-consistency/hestino/deploy/ |
Hestino Docker Swarm stack files, release manifests, and current deployment pointer. |
/srv/dream-consistency/hestino/scripts/ |
Deployment, rollback, maintenance, and verification scripts. |
/srv/dream-consistency/hestino/shared/storage/ |
Shared storage for application files if needed. |
/srv/dream-consistency/hestino/shared/logs/ |
Shared log output if applications write host-mounted logs. |
/srv/dream-consistency/hestino/backups/ |
Local backup staging area. |
Common commands for verifying Docker Swarm and Hestino stack status.
| Risk | Impact | Mitigation |
|---|---|---|
| Single-server architecture | If the server fails, all services on that server are unavailable. | Accept for initial DEV and early PROD. Add multi-server architecture later if needed. |
| MariaDB on host | Database is a critical stateful dependency. | Use strict backups, restricted access, and separate PROD database. |
| Worker duplicates | Multiple workers could process the same job twice. | Keep Hestino.Worker at 1 replica until locking and idempotency are implemented. |
Using latest images |
Unclear what version is deployed. | Use explicit version tags only. |
| Registry unavailable | New deployments cannot pull images. | Back up registry storage and keep already deployed images on servers where possible. |
| Question | Status | Owner |
|---|---|---|
| Should Nginx stay on host permanently or move to Swarm later? | Open | Branko |
| Where should ASP.NET Core Data Protection keys be stored for replicated Razor Pages? | Open | Branko |
| What is the final backup strategy for MariaDB, registry storage, and Docker volumes? | Open | Branko |
| Date | Change | Author |
|---|---|---|
| 2026-06-24 | Initial server architecture page created. | Branko |