Menu

Infrastructure is a design decision, not a leftover.

Red Sentra takes responsibility for the infrastructure and the delivery path a system runs through — how it is shaped, how a change reaches production, and what happens when it should not have.

Responsibility

What we take on.

  • The infrastructure a system runs on, designed rather than accumulated
  • Environments, and the differences between them being deliberate
  • The deployment path: how a change reaches production and how it comes back
  • Runtime and packaging, including what is not in the running process
  • The failure boundaries, and what each one costs to hold
  • Operating the result, where the engagement continues past the first deploy

Engineering

  1. The shape of the infrastructure is the first question

    Where a system runs decides what it is allowed to assume. Sentinel Solar runs on a small computer at the installation and talks straight to the inverter, so the network being absent is an ordinary Tuesday rather than an incident — that is an architecture, chosen before anything was deployed.

    The opposite mistake is a topology nobody chose: an environment that grew, a machine only one person understands, and a deployment that works because of something nobody has written down. Infrastructure designed after the fact is the same system with the reasons missing.

  2. What is in the running process

    RustSTT is Rust on Candle with no Python interpreter in the running service. That removes a whole class of packaging, dependency and interpreter problems from production, and weights are memory-mapped rather than loaded, so a process starts in about the time it takes to open a file.

    The same binary runs on CUDA in production and on CPU and Apple Metal elsewhere. A runtime that is one artefact across three accelerators is an infrastructure decision as much as an engineering one: it is what makes the deployment story short enough to hold in your head.

  3. The delivery path is part of the system

    A release path is not neutral plumbing. NutriSense reaches users through a store review and a device estate nobody controls, so a change is live for different people at different times and a rollback is not a button — the design has to hold that, not wish it away.

    Lexora moves slow work to background workers outside the request, which means the request path and the work behind it fail separately and are deployed with different risk. Deciding which parts may be released independently is where most of the reliability actually comes from.

  4. Where this ends and maintenance begins

    This page answers one question: take responsibility for the infrastructure and the delivery system this software runs through. The neighbouring question — take responsibility for this application and keep it healthy — is application maintenance and support, and it has its own page.

    In practice the two meet, and pretending otherwise would be a marketing convenience. The distinction that matters is the object: here it is the ground the system stands on; there it is the system itself.

Evidence

Systems this rests on.

Each entry names the contribution Red Sentra declared on that system. Nothing here is cited for work the content model does not carry.

  • RustSTT

    In productioninfrastructure

    One binary deployed across CUDA, CPU and Apple Metal, with memory-mapped weights and no Python interpreter in the running service.

  • Sentinel Solar

    Deployedinfrastructure

    An always-on backend on a small computer at the installation, where deploying means a device in the field and connectivity is not a precondition.

  • Lexora

    In productionoperations

    A commissioned product in production where slow work runs in background workers outside the request, so the request path and the work behind it fail and ship separately.

  • NutriSense

    In productionoperations

    A product released through Google Play, where a change reaches a device estate nobody controls and the release path is not under one team’s sole control.

Limits

What this page does not claim.

  • No cloud provider is named as a specialism. No partner status, certification or provider-specific delivery history is claimed for AWS, Azure or Google Cloud, because none is recorded.
  • No Kubernetes, service-mesh or platform-engineering engagement is described. The deployments in this portfolio are a GPU service, an edge device and containerised backends.
  • No uptime figure, incident count or deployment-frequency number is published, because none has been measured in public.
  • Red Sentra does not place an engineer inside another company’s rota. The engagement is the infrastructure and the delivery path as an outcome, not a seat.