Day by Day
Day by Day is an independent Linux and open-source infrastructure company, founded in 2005 by Gerben Meijer. We design, modernize, migrate, automate, and troubleshoot production infrastructure: from Linux and storage to Kubernetes, OpenStack, cloud platforms, and high availability.
The work is practical and outcome-focused. We work best with clear scope, useful documentation, and a clean handover, so the operating team can run and change the result confidently.
See the services overview for the areas we work in, or contact Day by Day to discuss a concrete platform, migration, automation, or troubleshooting need.
Services
Architecture, modernization, and migration work for Linux-based platforms: Kubernetes clusters, OpenStack clouds, public cloud, private cloud, VPS, and dedicated bare-metal environments. We evaluate capacity, reliability, cost, and operational risk before committing to a design.
Repeatable provisioning, configuration management, and delivery workflows using Ansible, Puppet, Ansible Tower/AWX, Cobbler, GitHub, and GitLab. The output is automation that can be reviewed, reused, and handed over—not scripts that only work once.
Reliability work for production platforms: runbooks, monitoring improvements, failure-mode review, high-availability changes, production-readiness fixes, and root-cause analysis across Linux, storage, networking, web, database, and platform services.
Focused troubleshooting, upgrade, and migration work where the problem or path forward is unclear. Work can cover performance regressions, upgrade breakage, hardware/software interaction, Kubernetes and OpenStack migrations, and Linux service transitions across web, database, identity, VPN, and network services.
Since 2005, Day by Day has helped organizations improve production infrastructure with Linux, open-source, cloud, storage, networking, Kubernetes, OpenStack, automation, migration, and high-availability work.
The work is practical and production-oriented: understand the risk, choose a sound path, implement the change, and leave the operating team with something they can run and change confidently.
Work usually starts with a clear platform problem or change: a migration that needs planning, automation that needs to be reliable, an upgrade that carries risk, or a production issue that needs root-cause analysis.
The goal is clear responsibility for the result: architecture that can be built, automation that can be maintained, documentation that is useful, and handover that leaves the operating team in control.
Contact