Managed operations
Managed operations is a contract-specific service around Tabbify Cloud. The platform provides a defined set of runtime signals today; a named engineer, support window, release runbook, recovery procedure, and response target exist only when they are written into a proposal or production agreement.
Evidence available today
The current platform can provide:
- asynchronous deploy status with the current build or activation stage;
- the configured health-gate result before a candidate is activated;
- current application lifecycle state on the selected host;
- a bounded tail of recent application output stored locally on that host;
- public route and tenant-private network checks;
- current state for the early-access data resources exposed to the account.
This evidence is useful for current diagnosis, but its retention and scope are limited. Tabbify Cloud does not currently provide durable deployment history, automated platform rollback, or a complete platform metrics, alerts, and traces service. Managed data does not currently provide complete HA, full DR, or universal PITR. A customer agreement may add human procedures around these gaps, but it does not turn an absent platform feature into an available one.
Engagement model
A managed engagement normally has three written stages:
- Architecture review. Map applications, repositories, data, external providers, traffic, current deployment flow, constraints, and operational pain.
- Bounded pilot. Move one representative path with observable acceptance criteria and a documented way to stop or reverse the migration itself.
- Managed scope. Agree responsibilities, service objectives, access, support window, data protection, escalation, and commercial terms for the accepted environment.
Early access is collaborative. The public website describes the product boundary; the signed proposal defines the human service for a specific customer.
Named engineer
When included in the agreement, a named infrastructure engineer maintains context for the accepted environment. Typical work can include:
- inventorying workloads and dependencies;
- preparing one or more agreed application migrations, each using one selected workload target;
- configuring public ingress, tenant-private networking, secrets, and health checks;
- connecting early-access data resources whose limits have been accepted;
- writing release, recovery, backup, restore, and escalation runbooks;
- reviewing current evidence and recurring failure patterns;
- coordinating infrastructure work during an incident.
"Named" means continuity and an accountable contact. It does not imply continuous individual availability, and it is not an SLA unless the agreement defines one.
Responsibility boundary
The exact matrix belongs in the pilot. A typical starting point is:
| Area | Customer product team | Tabbify under an agreed scope |
|---|---|---|
| Application | Own code, product behaviour, functional tests, and application auth | Provide runtime evidence and isolate platform causes |
| Releases | Choose source revision and acceptance criteria | Maintain the deploy path and configured health gate |
| Compute and network | Declare resources and approved exposure | Operate the accepted target, relay path, and edge configuration |
| Data | Own schema, queries, migrations, classification, and business retention | Operate only the named early-access resources and written protection procedures |
| Secrets and providers | Supply approved credentials and provider accounts | Store and inject secrets within the agreed access boundary |
| Incidents | Provide product context and business decisions | Coordinate the contracted infrastructure response |
Anything not written into scope stays with its existing owner. A healthy platform route can prove that a request reached the workload; it cannot prove that the application's business result is correct.
Migration pilot
A useful pilot contains a real application slice: one API or worker, one important dependency, and one public or private route.
Discovery
Record:
- repositories, build commands, artifacts, and entrypoints;
- CPU, memory, storage, locality, and latency requirements;
- inbound routes and outbound dependencies;
- databases, KV, object storage, retention, and recovery needs;
- current release frequency, failure modes, and recovery method;
- identities, secrets, operator access, and audit requirements.
Requirements outside the current product boundary become pilot blockers or explicitly excluded work. They are not silently treated as available.
Acceptance
Before traffic moves, verify the exact agreed path:
- build and deploy the chosen commit;
- observe asynchronous status and a passing health gate;
- serve the intended route through its configured TLS hostname;
- make required same-tenant private calls through the production relay;
- collect a bounded application-log tail from a known test failure;
- submit a known-good commit as the release recovery path;
- exercise the resource-specific restore path if data protection is in scope;
- confirm the escalation contacts and communication channel.
Acceptance should name identifiers and outcomes, for example: "commit X reaches running, serves route Y, and the agreed restore test reads marker Z." "The platform works" is not an acceptance criterion.
Releases and incidents
Application releases use the deploy pipeline. The current platform has no automated rollback command, so a runbook should identify the known-good source revision and the conditions for submitting it as a new deploy. Data migrations need their own forward-fix or restore procedure.
During an incident, a contracted named engineer can coordinate the infrastructure path: confirm impact, preserve available timestamps and log output, separate application from platform boundaries, apply the agreed stabilization procedure, communicate through the contracted channel, and record follow-up work.
Response targets, on-call hours, communication cadence, recovery objectives, and service credits are contractual choices. This page does not create them.
Start a pilot
Send the application shape, current hosting model, data dependencies, traffic profile, and the first operational problem to remove. Tabbify can then propose a bounded pilot with explicit acceptance criteria and limitations.