Supporting Infrastructure Add-ons

Data, observability, local development, CI runners, delivery platforms, DNS, and TLS operated around Assistance engagements

Supporting infrastructure add-ons help teams close specific operating gaps around a consulting, DevOps/SRE, platform, or delivery engagement. The offer is intentionally scoped: Assistance does not promise to host anything without assessment. We operate components where clear ownership, monitoring, backups, change control, and support boundaries can be agreed in advance.

Add-on catalogue#

Managed PostgreSQL Managed MySQL Managed MongoDB Managed Kafka Managed OpenSearch Managed Prometheus Managed Runners Managed GitLab Managed Gerrit Managed K3s Managed DNS Managed Certificates

What is included#

Every add-on starts with an agreed service boundary. Within that boundary, Assistance normally provides:

Operating area	Included responsibility
Assessment	Workload review, ownership gaps, risk level, deployment model, and service-level expectations
Provisioning	Architecture sizing, environment setup, network placement, secure defaults, and documented access details
Operations	Health monitoring, patch planning, version lifecycle guidance, maintenance windows, and capacity review
Reliability	Backup policies, restore validation where applicable, runbooks, incident triage, and recovery planning
Security	TLS, access control, credential rotation support, audit logging, and vulnerability review where applicable
Observability	Dashboards, alerts, escalation routing, usage metrics, and operational notes for support handoff
Change management	Planned changes, upgrade windows, rollback plans, and communication before customer-impacting work

Cloud provider charges, software licenses, application changes, data modeling, and unlisted platform work are scoped separately unless explicitly included in the engagement.

Ownership model#

Responsibility	Assistance owns	Customer owns
Service runtime	Installation, configuration, upgrades, monitoring, backups, failover procedures, and runbooks inside the agreed boundary	Application compatibility, client libraries, release timing, and product behavior
Access and secrets	Initial access model, service accounts, rotation procedure, and least-privilege recommendations	User approvals, identity source of truth, application secret consumption, and internal access reviews
Data and configuration	Backup/restore process, retention implementation, platform configuration, and recovery testing when scoped	Data classification, legal retention rules, schema ownership, DNS naming decisions, and application-level validation
Incidents	Platform triage, infrastructure remediation, status updates, and post-incident notes	Application incident lead, business impact decisions, and customer communications unless contracted
Cost	Sizing recommendations, utilization review, and Assistance operations pricing for the agreed scope	Provider spend, traffic growth decisions, retention requirements, and business trade-offs

SLA language is scoped, not generic

Availability targets, response times, exclusions, measurement windows, and recovery objectives are confirmed per add-on and deployment model. We do not apply a blanket uptime promise to systems we have not assessed or do not operate.

Deployment models#

Model	Best for	Notes
Local development and CI infrastructure	Runner fleets, test databases, internal tools, predictable build dependencies, and developer-platform support	Often paired with consulting or DevOps/SRE retainers to reduce delivery friction.
Assistance-operated physical servers	Development, CI/CD dependencies, staging services, and steady internal workloads	Flat-rate economics and dedicated hardware. Not a default promise for internet-scale production elasticity.
Customer cloud account	Production systems that must live inside your AWS, Azure, GCP, Oracle Cloud, or existing tenancy	You keep account ownership and billing. Assistance operates the agreed component inside defined boundaries.
Assistance-managed cloud tenancy	Teams that want Assistance to own more of the platform and operations surface	Useful when the add-on is part of a broader managed environment.
Hybrid	Development and CI on Assistance-operated infrastructure with production in your cloud account	Common for teams optimizing cost without giving up production cloud controls.

Selection guide#

Need	Recommended add-on
Transactional relational data, JSON support, geospatial, extensions	Managed PostgreSQL
Existing MySQL/MariaDB application, CMS, commerce, LAMP-style workload	Managed MySQL
Flexible document model, catalogs, mobile backend, semi-structured records	Managed MongoDB
Event streaming, CDC, integration bus, replayable event log	Managed Kafka
Full-text search, log analytics, dashboards over indexed data	Managed OpenSearch
Metrics collection, alerting, SLO dashboards, infrastructure visibility	Managed Prometheus
Faster, isolated, self-hosted CI/CD builds and local-dev parity	Managed Runners
Operated source, CI, permissions, backups, and upgrades for GitLab	Managed GitLab
Change-based code review with controlled access and operations	Managed Gerrit
Lightweight Kubernetes for edge, lab, and constrained environments	Managed K3s
DNS ownership, record changes, provider automation, and failover hygiene	Managed DNS
TLS issuance, renewal, internal PKI, and certificate expiry prevention	Managed Certificates

Onboarding process#

1. Assessment#

We review workload type, data sensitivity, availability expectations, traffic shape, backup requirements, compliance constraints, existing tooling, and the target engagement context.

2. Service design#

We propose the add-on configuration: topology, sizing, retention, backup or rollback approach, network access, identity model, monitoring, and support tier.

3. Build and migrate#

Assistance provisions the component, documents access, configures dashboards and alerts, and supports migration from self-hosted systems or cloud-native managed services when needed.

4. Operate and improve#

After go-live, we operate the agreed boundary, review capacity and incidents, schedule maintenance, and recommend improvements when usage or risk changes.

Common adoption scenarios#

Stabilize a dependency that slows delivery#

Teams often start with a database, runner fleet, DNS zone, or delivery tool maintained through tribal knowledge. Assistance turns that dependency into an operated add-on with monitoring, documented access, and an escalation path.

Standardize local development and CI#

Development databases, runners, and internal delivery services can run with predictable cost and stronger isolation while production stays in the customer cloud.

Add operational coverage without hiring specialists#

Use Assistance for DBA, streaming, observability, delivery-platform, DNS, and certificate operations while your internal engineers keep application and product ownership.

Getting started#

Start with an infrastructure assessment. We will map the add-ons you need, the operating boundaries, the deployment model, and the support language required for the engagement.

Request infrastructure assessment →

Frequently asked questions#

Is this a replacement for cloud-managed services like RDS, MSK, OpenSearch Service, Cloud DNS, or ACM? Sometimes. We can operate native cloud-managed services in your account, run open-source equivalents on dedicated infrastructure, or use a hybrid model. The right choice depends on cost, control, compliance, and operational requirements.

Who owns the cloud account and infrastructure bill? For customer-account deployments, you own the account and provider bill. Assistance owns the agreed operational responsibilities and charges a service fee for that scope.

Can you migrate existing production data or platform configuration? Yes, when migration is scoped by size, downtime tolerance, compatibility, access, and rollback needs. Data, DNS, delivery-platform, and certificate migrations all require an explicit cutover plan.

Do all add-ons include 24/7 support? No. Monitoring and support are defined by the selected plan. Critical response is available for covered production services, but it is not implied for every assessment or development-only environment.

Can we keep application ownership? Yes. Assistance operates the infrastructure add-on. Your team keeps application architecture, schema decisions, business logic, release timing, and customer-facing product decisions unless a broader service agreement says otherwise.