How an engagement works
An engagement with DJ2 Services starts with a paid diagnostic. A fixed-scope build can follow; an ongoing retainer becomes an option after the platform reaches an agreed baseline. You approve each phase before it starts.
Duration: typically one to three weeks.
Purpose: agree the target architecture and price the implementation work.
Scope can include:
- Current-state infrastructure inventory
- Workload placement analysis
- Public-cloud and private-cloud boundary design
- Colocation and network requirements
- Proxmox versus OpenNebula platform decision
- Server, storage, backup, and capacity requirements
- VLAN, routing, firewall, VPN, and management-plane design
- AWS account and network integration
- Kubernetes placement and dependency review
- Security and access requirements
- Migration phases, risks, and acceptance criteria
Deliverables: an architecture diagram, a responsibility matrix, equipment requirements, and a network and address plan. The package also records the platform choice, the migration or build plan, and the implementation work with fixed-scope options.
Purpose: implement the diagnostic's plan at an agreed fixed scope and price.
Typical work:
- Private-cloud deployment (Proxmox or OpenNebula)
- Network and firewall configuration
- AWS integration
- Linux hardening
- Backup and recovery setup
- Kubernetes integration
- Terraform and Ansible automation for repeatable changes
Scope: builds can cover small and midsize environments or complex multi-node and regulated platforms. The diagnostic defines and prices the work before implementation starts.
Purpose: reserve engineering hours for recurring platform work once the build reaches an agreed baseline.
Monthly capacity options:
- Hybrid Platform Stewardship: up to 12 engineering hours per month for one private site and one public-cloud environment.
- Managed Hybrid Platform Engineering: up to 25 hours per month for multi-node private cloud, AWS, network edge, and routine platform changes.
- Reserved Platform Engineering: up to 50 hours per month for complex multi-site, regulated, Kubernetes, or frequently changing platforms.
Limits: the retainer reserves a defined amount of engineering time. The contract sets any rollover allowance; unused hours do not accumulate without limit. Projects outside that scope need a separate statement of work. Emergency physical work and travel are charged separately.
What a retainer can cover
Each retainer names the modules and work it covers. General managed IT support is outside the service.
- Private cloud: Proxmox or OpenNebula upgrades, host configuration, VM standards, capacity, and storage. Guest operating system administration has its own agreed limits.
- Network & colocation: MikroTik configuration, VLANs, firewall rules, VPNs, management networks, and IP plans. Carrier and data-center remote-hands charges are separate.
- AWS platform: accounts, identity, networking, compute, storage, security controls, and cost reviews. Application development remains the customer's responsibility.
- Kubernetes platform: EKS, OneKS, or private-cluster changes, upgrades, policies, and automation. Application ownership stays with the customer.
- Backup & recovery: backup configuration, restore checks, and planned recovery exercises using tested designs.
- Security & evidence: hardening, access reviews, logging, change records, and evidence to support your audits.
The review and maintenance schedule
Monthly
- Review platform capacity, backup status, access changes, and planned lifecycle work.
- Review approved configuration changes and infrastructure code, then apply scheduled changes inside agreed windows.
Quarterly
- Review platform versions, lifecycle dates, and recovery procedures; test selected restore paths.
- Review network boundaries, privileged access, configuration drift, and cost assumptions.
Annual or major-event work
- Large migrations, site moves, hardware refreshes, major upgrades, and disaster-recovery redesigns run as separate projects with their own scope.
Customer-owned infrastructure
DJ2S recommends keeping hardware, cloud accounts, software licenses, carrier services, and colocation contracts in your organization's name. Customer-owned hardware in colocation is the preferred model. Deployments at customer sites can fit vendor appliances, regulated workloads, or site-specific requirements. DJ2S-owned infrastructure would be considered only if several qualified customers independently requested it.
DJ2 Services (DJ2S) builds, secures, and operates hybrid infrastructure across AWS, colocation, private compute, and Kubernetes. Hardware and cloud accounts remain customer-owned.