OpcotechOpcotech

Cloud & Platform Engineering

Infrastructure your engineers don't fight.

Opcotech designs, builds, and improves the systems behind software delivery. From CI/CD and Kubernetes to cloud infrastructure and internal platforms, we remove the work that slows developers down and makes production difficult to operate.

For software companies that have outgrown ad-hoc infrastructure but don't need a large internal platform team to fix it.

Supported path

  • the change
  • platform

What an engineer does

  1. Commit
    What the platform carries:
    • Service template
    • Environments
  2. Build
    What the platform carries:
    • CI
    • Registry
  3. Deploy
    What the platform carries:
    • GitOps
    • Clusters
    • IAM
    • Secrets
  4. OperateRunning in production
    What the platform carries:
    • Metrics
    • Traces
    • Alerts
    • Costs
Four steps for the engineer. The parts underneath each step are the platform’s job.

The problem

Your infrastructure wasn't designed this way. It happened.

A few pipelines, cloud resources, and deployment scripts worked when the team was small. Now, multiple environments, Terraform repositories, clusters, and access policies make even routine changes slow and unpredictable.

Engineers lose hours fixing pipelines, waiting for environments, and navigating infrastructure differences instead of building features. Releases take longer, infrastructure costs grow, and incidents pull senior engineers away from planned work.

The problem isn't necessarily the technology. It's the lack of a system connecting it.

Opcotech helps turn those disconnected parts into an engineering platform with clear ownership, repeatable workflows, and fewer decisions for product teams to make.

How it grew

  • Undocumented dependency

Then · 3 parts

  1. Code
  2. Deploy
  3. Cloud

Now · 12 parts

  • Code
  • CI
  • Registry
  • GitOps
  • Clusters
  • Services
  • IAM
  • Secrets
  • Metrics
  • Traces
  • Alerts
  • Costs
3 parts in a line became 12, joined by dependencies that were never designed and are rarely written down.

Outcomes

What gets easier when the infrastructure works together.

01

Shipping software

Make software delivery a repeatable, reliable process rather than a coordinated effort every time you release.

We design and improve CI/CD pipelines that automate builds, testing, security checks, and deployments across your environments.

By standardizing workflows, documenting release procedures, and removing unnecessary manual steps, we help your engineering team deploy changes more frequently, reduce release-related risks, and spend less time managing the delivery process.

02

Operating production

Give engineers useful signals, predictable deployments, and a recovery path they can follow when something fails.

03

Changing infrastructure

Replace one-off configurations with reviewed, reusable infrastructure code and clear boundaries between teams.

04

Understanding cloud costs

Connect infrastructure spending to the services and decisions that create it. Find waste without compromising reliability.

The system

A platform is more than its components.

A reliable platform connects the developer experience, delivery pipeline, runtime, and cloud foundation. Each layer needs a clear interface with the next. Teams should know what they can change, what the platform provides, and who owns the exceptions.

Layers and what runs across them

  • interface between layers
  • reliability

Layer

  • Monitoring
  • Incident response
  • Security
  • Cost visibility
  1. 01

    Developer experience

    Service templates, environments, and supported workflows that make the routine path easier.

    Interface to the next layer:a path delivery can run

  2. 02

    Delivery

    CI/CD, artifact management, deployment, and promotion between environments.

    Interface to the next layer:a release the runtime accepts

  3. 03

    Runtime

    Kubernetes or another runtime, with shared workload expectations and an upgrade path.

    Interface to the next layer:a foundation under the runtime

  4. 04

    Cloud foundation

    Cloud accounts, networking, identity, and security controls that underpin the runtime.

Reliability

Monitoring, incident response, security, and cost visibility built into the system rather than added afterward.

Each layer hands the next a defined interface. Reliability is threaded through every layer instead of sitting beside them.

Work

What changed.

  • Open-source Software

    RethinkDB - Infrastructure Recovery

    RethinkDB's release infrastructure needed recovery and modernization with the least possible disruption on existing installation and update workflows. The rebuild had to preserve repository compatibility, package signing, and the established download domain while supporting reliable software distribution across Linux environments.

    • Infrastructure provisioning

      UI-managed Linode VMsTerraform-managed DigitalOcean Droplets

    • Server configuration

      Manual server configurationAnsible-managed configuration

    • Recoverability

      Lack of backupsAutomated daily and weekly backups

  • Open-source Software

    RethinkDB - CI/CD Pipeline Rebuild

    Opcotech rebuilt RethinkDB's CI/CD infrastructure using GitHub Actions, replacing an unmaintainable legacy setup with transparent, version-controlled workflows and restored release artifact infrastructure.

    • CI/CD configuration availability

      LostVersion-controlled

    • Pipeline maintainability

      Legacy-dependentCommunity-owned

    • Packaging portability

      Coupled & PrivateIndependently executable

Engagement

Start with the problem. Build what matters. Keep ownership.

Each step has a defined deliverable. Your team keeps the system.

Who holds the system

  • owns the system
  • only if useful
  1. 01

    Assess

    We examine the current infrastructure, trace how software reaches production, and identify the constraints worth addressing first.

    DeliverableA documented assessment and prioritized engineering roadmap.

  2. 02

    Engineer

    We implement the agreed changes in your infrastructure and repositories, alongside the people who will maintain them.

    DeliverableWorking engineering changes, documented decisions, and a handover.

  3. 03

    Evolve

    Only if useful

    If continued expertise would help, we can provide an ongoing senior platform engineering capability without taking ownership away from your team.

    DeliverableAgreed ongoing engineering work, not an indefinite dependency.

Opcotech works through Assess and Engineer, then hands over. Your team owns the system from then on. Evolve is optional.

Opcotech works inside your repositories until the handover. Your team holds the system from then on, with or without us.

Explore our approach

Platform assessment

Know what needs fixing before committing to a rebuild.

Our Platform & DevOps Assessment examines the infrastructure, delivery process, operational risks, and cloud costs you already have. You receive prioritized findings and a practical 90-day roadmap, including what to fix first, what can wait, and what should be left alone.

Technology

Experienced with the tools. Not attached to them.

We work across AWS, GCP, Kubernetes, Terraform, OpenTofu, GitHub Actions, GitLab CI, Argo CD, Prometheus, Grafana, and related infrastructure tooling. We prefer working with the systems your engineers already understand. Replacing a tool is worthwhile only when the replacement solves a problem that configuration or architecture changes cannot.

Cloud
  • AWS
  • GCP
Platform
  • Kubernetes
  • Docker
  • Cilium
  • Istio
Infrastructure
  • Terraform
  • OpenTofu
  • Ansible
Delivery
  • GitHub Actions
  • GitLab CI
  • Argo CD
Observability
  • Prometheus
  • Grafana
  • OpenTelemetry

Insights

Engineering notes from the decisions behind the systems.

Technical arguments about infrastructure, delivery, and reliability. Written for people who work with these systems and want a clearer way to reason about them.

Read the insights
  • DevOps

    GitOps is a delivery model, not a tool install

    Argo CD alone does not establish GitOps. The important decisions concern desired state, environment promotion, ownership, and handling configuration drift.

    Installing Argo CD or Flux does not automatically give you a GitOps delivery process. GitOps requires decisions about where desired state lives, who can change it, how changes reach production, and what happens when the running environment differs from Git.

  • Platform engineering

    What to look for in a platform assessment

    A platform assessment should identify the constraints affecting delivery, reliability, and cost, then produce engineering work your team can actually execute.

  • Infrastructure as code

    When a Terraform repo stops being a platform

    Infrastructure code becomes a bottleneck when state, modules, and deployment responsibilities lack clear boundaries. Here's what to separate first.

What is your infrastructure making harder than it needs to be?

A slow release process, an unreliable cluster, infrastructure nobody wants to change, or a cloud bill nobody can explain. Tell us what is happening. We'll discuss where the constraint might be and whether we can help.