The Boundary in Detail

This page lists the responsibility boundary layer by layer, naming the specific technologies involved, and what is not yet self-service. For the short version, see What You Can Do vs. What We Manage.

Kubernetes

CTO2B manages:

• Provisioning and upgrading EKS clusters
• Node group health and scaling
• Platform-level Kubernetes components and platform namespaces

You manage:

• Your application manifests and Helm charts
• Setting appropriate CPU and memory requests/limits for your pods
• Your container images

Boundary example: If your pods are being evicted due to memory pressure — check whether your resource limits are set correctly before raising a request.

Deployments & GitOps (ArgoCD)

CTO2B manages:

• Running and maintaining ArgoCD
• The app-of-apps structure that manages your applications
• Investigating sync failures caused by platform issues

You manage:

• Your Helm values and Kubernetes manifests in your Git repo
• Keeping your container image tags up to date
• Fixing sync failures caused by your own configuration changes

Boundary example: If ArgoCD shows your app as OutOfSync because of a bad image tag or broken manifest — that's yours to fix. Your Customer Success Engineer can advise, but won't edit your Git repo.

Databases (AWS RDS)

CTO2B manages:

• Provisioning the RDS instance
• Engine version and security patching
• Automated backups and retention
• Instance sizing (with your input on growth expectations)
• Network security and connectivity to your cluster

You manage:

• Your database schema and its evolution (migrations)
• Query performance and index strategy
• Application connection strings and credentials rotation
• Stored procedures, triggers, and custom database functions

Boundary example: Slow queries, N+1 problems, and index tuning are application-layer concerns. If database response times increase due to infrastructure (e.g., IOPS limits, storage pressure), CTO2B will investigate.

Ingress & networking

CTO2B manages:

• Running Traefik as the ingress controller
• Provisioning and renewing TLS certificates automatically via cert-manager
• Load balancer (AWS NLB) configuration

You manage:

• Your domain DNS records — pointing your domains at the load balancer is your responsibility. Domain ownership and your DNS or proxy provider account remain yours.
• The routing rules in your Ingress manifests
• Choosing hostnames and path routing for your services

Boundary example: If your application URL is not resolving, first check that your DNS record is pointing to the correct load balancer address. If DNS is correct and the platform ingress is healthy, open a Sev-2 support request.

Observability components

CTO2B manages:

• Deploying and maintaining Prometheus, Grafana, and Loki
• Platform-level alert rules and routing to your Slack channel
• Grafana access provisioning

You manage:

• Reading and interpreting your application's own metrics and logs
• Custom dashboards for your application (not included in standard support)
• Tuning your own alert thresholds (requires a request to action)

CTO2B deploys a monitoring stack on every cluster for its own operational use.
That stack is not visible to your team, and its alerts route to CTO2B, not to
you. If your team wants its own Grafana dashboards, metrics, and logs with admin
access, you can request a dedicated observability stack. It is opt-in and
provisioned on request. Once you have it, building dashboards, setting alert
thresholds, and routing your own alerts are yours to manage. See
Observability.

Boundary example: CTO2B will tell you if your cluster is unhealthy. Reading your application logs to diagnose a bug is your team's job.

Security

CTO2B manages: platform RBAC, standard network policies, and access tooling.

You manage: your application's own authentication and authorisation.

CI/CD

CTO2B manages: everything from the container registry onward.

You manage: everything up to the image push — code, build, and pipeline configuration.

Not yet self-service

Raise a request for anything in this list.

Infrastructure

• Creating new Environments or namespaces — include the environment name,
  cloud provider, and stage
• New Kafka topics or users — see Kafka Access, ACLs and Topics

Cloud console access

• AWS IAM users — for CI/CD pipelines, external SaaS, or other third-party
  integrations; see AWS S3 and IAM Access
• AWS S3 bucket policies — cross-account or cross-service access beyond what
  the Catalog provisions; see AWS S3 and IAM Access
• IAM Service Accounts — for third-party integrations or Workload Identity;
  see GCP IAM and GCS Access
• GCP cross-project IAM permissions — see GCP IAM and GCS Access
• DNS configuration — pointing a custom domain at the PushOps load balancer;
  see Ingress, Custom Domains and TLS

Networking

• CloudFlare traffic shielding — restricting your load balancer to accept
  traffic only via CloudFlare; requires CloudFlare Proxy active on your domain;
  see Ingress, Custom Domains and TLS
• Cross-namespace network policies — see Network Policies
• Egress restriction — locking outbound traffic to specific external
  endpoints for compliance; see Network Policies

Access and roles

• Role changes — a different SVIEW role or additional permissions; see
  User Profile

Compliance

• Audit evidence packages — platform-level evidence for SOC 2, DORA, or
  other audits; see Audit Logs, SOC 2 Compliance on the PushOps Platform, Digital Operational Resilience Act (DORA)

Related articles

• What You Can Do vs. What We Manage — the summary
• SLA Policy — severity levels and response targets
• Getting Help — how to raise a request