#CapRover Consulting

CapRover is a self-hosted PaaS. You bring the machine; it provides the Heroku-like layer — a web panel, CLI, Nginx reverse proxy, automatic HTTPS, and 100+ one-click apps. We help independent developers and small teams go from a blank VPS to a platform they can actually run.

This is not a Kubernetes engagement. If you already need multi-AZ elasticity, full RBAC, or Docker Compose as a first-class citizen, we will say so in the first conversation and point you elsewhere.

#How this relates to official support

CapRover's own Help and Support page splits help into three lanes. We sit in the third:

We do not replace the project, and we do not sell official CapRover Pro licenses. Product defects still belong on GitHub.

#Who we serve

• Independent developers and small teams hosting side projects, internal tools, or content sites on their own VPS
• Growing companies that want Heroku-style deploys, with data and invoices staying on machines they control
• Teams with a complicated stack — or many apps — to move onto CapRover
• Teams that already installed CapRover and are stuck on HTTPS, CI, disks, backups, or a panel they can no longer open
• Teams whose machines cannot reliably reach Docker Hub, GitHub, or the public one-click catalog

#Engagement length

• Hourly consultation (screen-share, one incident, plan review): billed by the hour
• Assessment only (CapRover vs Coolify / Dokploy / 1Panel / Kubernetes): 1–2 days
• Incident rescue: 1–3 days
• Single module: 3–7 days
• Full landing (install → apps → CI → backup → hardening): 2–4 weeks

#What we offer

#1. Hourly consultation

The official support page lists hourly third-party consultation as a first-class option. Use this when you do not need a multi-week project: a deploy that will not go green, a plan you want reviewed before buying the VPS, or a pairing session while you click through the panel.

You leave with a written note of what we changed, what we ruled out, and the next safe command — not a Slack transcript.

#2. Platform landing

Typical failures: :3000 never opens; Docker Hub times out on a China VPS; wildcard DNS is wrong so every app fails Let's Encrypt; the panel is still on the default password; ICP filing or a Cloudflare orange-cloud proxy blocks HTTP-01.

We choose the machine path (China lightweight cloud vs overseas VPS), install Docker the official way, set swap and registry mirrors, bind the root domain, Enforce HTTPS, close the install port, and leave a hidden-root-domain layout for the next box.

#3. Application onboarding and stack migration

This is the work the official third-party listing calls out: a complicated stack, or many applications, that need to land on CapRover.

Typical failures: a one-click app loses data after restart because Persistent Directories were never mounted; WordPress, n8n, or MinIO comes up as two apps and the database host is wrong; someone runs docker compose up on the same host and fights CapRover for ports; a Compose file is pasted in as-is and half the fields are silently ignored.

We put each app through the same three steps — custom domain, HTTPS, persistent directories — wire services over srv-captain--, and convert an existing Compose / Heroku / bare-Docker setup into CapRover apps and TEMPLATEs.

#4. CI/CD and private registries

Typical failures: a 1G box is OOM-killed while building a frontend; GitHub webhooks never reach a China VPS; pull access denied from ghcr, ACR, or Harbor; Image Prefix case is wrong; Default Push is left on a read-only registry; the panel password is sitting in GitHub Secrets.

We pick one path: a Gitee webhook, or GitHub / GitLab build-then-push with caprover deploy -i. We register the private registry (the official four-tuple), switch CI to App Tokens, and leave a repeatable captain-definition.

#5. Production hardening

Typical failures: the disk fills with old images or unbounded container logs; 502 because Container Port is 80 while the process listens on 3000, or the app binds 127.0.0.1; MySQL is mapped to the public internet; a hand-edited Nginx snippet blacks out the panel; every release flashes 502 because there is no HEALTHCHECK.

We install the daily runbook: panel Disk Cleanup, log rotation, CPU and memory overrides, public firewall limited to 80/443, databases kept on the overlay network, and the security checklist (HTTPS, closed :3000, fail2ban on SSH, hidden root domain). For stateless apps we add health checks, start-first updates, and automatic rollback.

#6. Backup, restore, and machine migration

Typical failures: people download backup.tar and believe the machine can be thrown away. The built-in backup is experimental and covers /captain/data only — images and volumes are not in the tarball. Starting CapRover before copying the tar means the empty instance will never ingest it. volume prune during a crashed database deletes the data.

We set up a 3-2-1 layout: a scheduled config tar in object storage, daily mysqldump / pg_dump / mongodump, and images in a third-party registry. Then we rehearse a move onto a spare machine: empty /captain → place backup.tar → start CapRover → repoint DNS → pull images → reload dumps.

#7. Team one-click marketplace

Typical failures: every new machine re-pastes TEMPLATE YAML; internal stacks, pinned tags, and Chinese runbooks do not belong in the public official repo; Connect is pointed at a git URL instead of the static origin; GitHub Pages is unreachable from the China host that runs the panel.

We publish a private catalog from a repository template, package one to three of your stacks (after they pass TEMPLATE), Connect it to your CapRover instance(s), and — when Pages is the wrong host — serve dist/ from a box the panel can actually GET.

#8. Restricted and air-gapped networks

Official CapRover depends on the public internet for code hosting, image pulls, health checks, and one-click catalogs (GitHub, Docker Hub, and similar). Plugins such as Netdata and many one-click apps may also call their own backends. The official page treats a fully airtight cluster as private vendor support.

We cover the cases that sit next to that:

• A China VPS that cannot reach Docker Hub or GitHub
• An intranet that may only pull from Harbor / ACR
• A local or self-hosted one-click catalog, so the panel does not have to GET the official marketplace
• Image bundles and a private registry, so deploys do not wait on the public Hub
• Turning off or replacing phone-home components when they are not acceptable

A machine that must never open an outbound connection at all — no mirror, no private registry, no exception — is the official airtight case. We will tell you in the first hour if that is what you actually need.

#Process

#1. Intake

After you write to us, we schedule a working interview: current hosting, why CapRover, China vs overseas constraints, who will operate the box, and what "done" looks like. Hourly work can skip to a screen-share if the incident is already on fire.

You provide:

• Current architecture, or a blank VPS
• Domain and DNS access
• A contact for each system we will touch

#2. Plan

We write down the machine path, DNS layout, app list, CI path, backup layers, and an explicit out-of-scope list. Example: joining a second node does not make MySQL highly available — persistent apps stay pinned to one disk.

You confirm:

• The plan and the success criteria

#3. Implementation

We land the modules you bought, in the order the platform actually requires: install and HTTPS before apps, registry before CI, dumps before any disk cleanup.

You provide:

• SSH or cloud-console access
• Application source or images, and registry credentials if they are private

#4. Drill

We do not hand over a box that has only been deployed. Depending on scope we rehearse one of: a failed release rolling back, a config-plus-data restore, or a move to a second machine.

You provide:

• A tester who can click through the apps
• A maintenance window if we are moving a live machine

#5. Hardening pass

We close leftover ports, set log and memory limits, confirm databases have no public mapping, and walk the security checklist against the running box.

#6. Handoff and training

We leave a short runbook — how to deploy, how to read logs, how to restore — and train the people who will operate the platform. A full landing includes 15 days of follow-up questions.

#Contact

Email hi@thematrixcrop.com. Tell us whether you need an hour on a live incident, a first install, a stack migration, or a production hardening pass.