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.

Infrastructure platform choices are Managed Kubernetes, Managed Proxmox, and Local Private Cloud. Managed Proxmox and Local Private Cloud are explicitly based on physical servers / dedicated physical hardware. The Managed Proxmox hub now includes evaluation, physical-server prerequisites, architecture, storage/networking, backups, monitoring/security, onboarding/migration, and day-2 support pages. Use Local Development for the facilitated local-development concept that combines managed git servers, runner fleets, collaboration tools, parity workflows, and onboarding/support boundaries.

Use Managed Git Server as the canonical source-control entry. GitLab, Gerrit, Gitea, and Forgejo remain option runbooks inside that guide, not separate top-level service choices. DNS and certificates are documented here as supporting responsibility guides because they affect platform safety, cutovers, and TLS hygiene, but they do not create a generic DNS or certificate hosting promise.

Add-on catalogue#

Managed PostgreSQL

Managed MySQL

Managed MongoDB

Managed Redis

Managed Kafka

Managed OpenSearch

Managed Prometheus

Managed Runners

Managed Git Server

Managed Artifact Repositories

Managed Docker Registry

Managed Kubernetes

Managed Proxmox

Local Private Cloud

Managed Mattermost

DNS operations guide

Certificate lifecycle guide

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
Facilitated local-development infrastructure	Managed git servers, runner fleets, test databases, internal tools, Mattermost, predictable build dependencies, and developer-platform support	Often paired with consulting or DevOps/SRE retainers to reduce delivery friction.
Assistance-operated physical servers	Managed Proxmox, Local Private Cloud, development, CI/CD dependencies, staging services, and steady internal workloads	Flat-rate economics and dedicated physical 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
Cache, sessions, rate limits, queues, pub/sub, real-time data structures	Managed Redis
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 overview as part of Local Development
Need an operated source-control, review, and CI/CD platform	Managed Git Server as part of Local Development
Need GitLab, Gerrit, Gitea, or Forgejo detail after platform selection	Use the option runbooks linked from Managed Git Server
Private packages, dependency caches, release artifacts, Helm charts	Managed Artifact Repositories
Docker/OCI image publishing, promotion, retention, and scanning workflows	Managed Docker Registry
Container platform operations with GitOps, ingress, observability, and workload boundaries	Managed Kubernetes
VM/LXC virtualization on physical servers or dedicated physical hardware	Managed Proxmox
Private platform on physical servers or dedicated physical hardware	Local Private Cloud
Customer-controlled team communication for local-development workflows	Managed Mattermost
DNS ownership, record changes, provider automation, and failover hygiene	Managed DNS responsibility guide
TLS issuance, renewal, internal PKI, and certificate expiry prevention	Managed Certificates responsibility guide

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.