FAQ
Questions we get asked before the first engagement.
If something here is unclear, or your question is not covered, ask us directly — we will give you the same answer in email that we would give on a call.
Working together
- Are you a staff augmentation company?
- We can provide engineering capacity when that is genuinely what is needed, but it is not our preferred model. We would rather own a defined cloud or platform scope, or deliver a scoped project, than rent hours. Owning a scope means we are accountable for an outcome; renting hours means you are accountable for directing us, which is usually the thing you were trying to avoid.
- Do you replace our internal DevOps team?
- No. DeClouder either complements an internal team — taking a defined part of the platform so your engineers can focus elsewhere — or provides the platform capability for companies that do not yet need a full internal organization. Where an internal team exists, we agree the boundary between us explicitly.
- Can you work with our existing development team?
- Yes, and this is one of the most common ways we engage. Your developers stay on the product; we take the infrastructure and platform work, review changes that touch it, and keep the paths they use to ship working.
- Can you be our platform team rather than sitting next to one?
- That is a common arrangement. We own a defined platform scope — the cloud environment, the clusters, the pipelines, the Infrastructure as Code — and your engineers own the application and its path to production. When you eventually hire a platform engineer, they inherit documented infrastructure in code rather than a decade of undocumented decisions.
- How do engagements get scoped?
- A conversation, then an assessment of the actual environment, then a written scope covering what we own, what stays with your team, and how support and coverage work. Major projects or work outside an agreed managed scope are scoped separately rather than absorbed.
- Do you publish pricing?
- No. Scope varies enough between environments that a public price would be misleading. Pricing is proposed after we understand what you are running and what you need us to own.
AI and delivery
- Do you use AI to operate production systems?
- AI assists our engineering workflows — investigation, drafting infrastructure code, review, documentation, automating routine work. AI-assisted changes travel the same path as any other change: automated validation, a pull request, policy and security checks in the pipeline, engineering approval, then GitOps reconciliation. Production workflows are designed around appropriate validation, approval gates and least-privilege access, and an engineer stays accountable for what reaches your production environment.
- Where does AI actually help?
- Mostly in work that is mechanical or investigative: reading across logs, metrics, manifests and configuration to narrow a problem; drafting and reviewing Terraform and Kubernetes manifests; analysing pipeline failures; generating tests, runbooks and documentation; and applying repetitive changes consistently across many repositories. We use AI coding agents and agentic workflows for this, integrated through MCP and agent SDKs with least-privilege access to engineering systems.
- Why does that matter to us?
- It is why a small senior team can carry the scope it does. You get experienced engineers rather than a larger team of mixed seniority, and the repetitive parts of the work do not consume the hours you are paying for judgment.
Support and operations
- Do you offer 24/7 support?
- Support and coverage are defined as part of each engagement, based on the customer requirements and what the environment genuinely needs. We would rather agree realistic coverage we can honour than advertise a blanket promise.
- Is there a limit to what a managed engagement covers?
- Every managed engagement has an agreed scope. Routine operational work, changes and improvements within it are covered, and larger projects are scoped separately so both sides know what is included.
- How do you handle access to our environment?
- Access is scoped to what the engagement requires, granted through your own identity and access controls, and reviewed as part of the engagement. Least privilege applies to us as much as to anything else we would recommend.
- What happens if we want to take the work back in-house?
- That is a normal outcome, and it is one reason we keep infrastructure in code and documentation current. Handover means transferring code, documentation and context — not extracting you from a dependency.
Technology and scope
- Which clouds do you work across?
- AWS, Azure and GCP, including their managed Kubernetes services — EKS, AKS and GKE — and hybrid estates where some infrastructure is still yours to run. Plenty of the environments we work in span more than one. Tell us what you are running and we will be specific about how we would approach it.
- What technologies do you support?
- The core ground is Kubernetes and managed Kubernetes, Terraform and Infrastructure as Code, CI/CD systems including GitHub Actions, GitLab CI, Jenkins and Azure DevOps Pipelines, GitOps with Argo CD or Flux, observability built around OpenTelemetry, Prometheus, Grafana and the cloud-native monitoring stacks, cloud networking, and the security tooling that belongs in a pipeline. The Capabilities page lists this by domain in detail.
- Do you do platform engineering, or just operations?
- Both, and platform engineering is a large part of our identity. That means the platform your developers build on: Kubernetes, golden paths, self-service environments, reusable infrastructure templates, standardized CI/CD and guardrails — so application developers can consume infrastructure safely without every developer becoming a cloud expert.
- Do you work with GitOps?
- Yes, and we will usually recommend it. Git as the source of truth, changes proposed by pull request, declarative configuration, automated reconciliation with Argo CD or Flux, an auditable history of what changed in production, controlled promotion between environments, and drift removed rather than managed.
- Do you take on-call or incident response?
- We can, and reliability work is a distinct service area — SLI and SLO design, incident response and management, root-cause analysis, capacity planning, DR and failover testing, on-call design and runbooks. What coverage looks like is agreed per engagement rather than advertised as a blanket number.
- Can you help with SOC 2, PCI DSS, HIPAA, CIS or NIST?
- We help engineering teams implement and operate controls aligned with those frameworks: infrastructure controls, hardening, access management, logging and the evidence an audit expects. Formal audit and certification stay with your auditor.
- Do you manage our databases?
- We support databases as part of the broader platform and infrastructure environment — provisioning, high availability, version upgrades, backup and restore testing, replication and failover, monitoring and integration — across PostgreSQL, Aurora and RDS, SQL Server, Cosmos DB, Redis, OpenSearch, Kafka and similar. Schema and query design stay with your engineers.
Still have a question?
Ask it directly and an engineer will answer.