Docker / Linux / deployment support

SPEC

Technical spec

Infrastructure: Docker
Linux
Caddy
systemd

FIT

A good fit when

One person performs every deployment by hand
Development and production differ, so something breaks on each release
A new server has arrived and the starting point has to be decided

PREBUILT

Example components

These components illustrate the proposed structure. Template features and scope will be confirmed after implementation and verification.

Container layout: A Docker Compose setup that separates the application, the reverse proxy, and the database.
HTTPS and domain setup: Reverse proxy configuration where certificate issuance and renewal run automatically.
Service and restart rules: systemd registration, log locations, and restart conditions, so a reboot returns the same state.
Deploy and rollback runbook: Deploy, rollback, and check steps written command by command, so a handover changes nothing.

The layout and design are adapted to each project.

SCREENS

Example screens

Example screens are being prepared.

SCOPE

In scope

Deliverables

Dockerfile and runtime configuration
Deployment procedure documentation
HTTPS and reverse-proxy configuration

In scope

Review of the current deployment approach and server environment
Container configuration and runtime settings
HTTPS, reverse proxy, and basic logging setup
Accompanying one deployment and verifying the procedure

Out of scope

Server, domain, and certificate costs
24-hour incident response and continuous monitoring
Application feature development
Responding to organisational security policy reviews

Scope and exclusions are defined before the work starts. The schedule and detailed terms are fixed in the SOW after we talk.

The problem this solves

When deployment depends on someone remembering the steps, recovery and handover become difficult. Recording the configuration and the procedure as documents and code makes the same result reproducible at any time.

How it runs

Review the current deployment approach, server environment, and constraints.
Fix the target configuration and procedure in the SOW.
Write the container configuration and server settings.
Run a real deployment together and verify the procedure.

Scope versus additional development

Deployment that does not follow the configuration and procedure in the SOW is a defect. Adding new environments, zero-downtime deployment, and building monitoring systems are additional work and are quoted separately.

FAQ

Frequently asked questions

Can the existing server be reused?: Yes. After reviewing the current environment, the proposal separates what changes from what stays.
Is CI/CD included?: The base scope is a reproducible deployment setup and procedure. Building a CI/CD pipeline is added to the scope and defined separately.

Need a particular setup?

Tell me which screens and integrations you need, and I will come back with what is feasible.

Ask about this setup