ClowdOps Private Deployment: Local Agent Operations for Teams That Need Control

ClowdOps is moving into a new phase.

The platform was already built around one clear idea:

Talk to your cloud. Talk to your BI. Talk to your operation layer.

The latest work led by Javier brings that idea closer to the environments where many serious teams actually need it: private infrastructure, internal networks, regulated setups, sovereign environments, and local operations where credentials, prompts, agent output, and infrastructure data must stay inside the customer’s perimeter.

ClowdOps now has a documented private deployment path.

That means a team can run the whole ClowdOps stack on infrastructure it controls: its own VPS, its own domain, its own identity provider, its own backups, its own credentials, and its own operational boundary.

The product does not become a weaker local demo. It remains the same ClowdOps operating model: chat, sandboxes, schedules, guardrails, notifications, resources, credentials, cost caps, SSO, and auditability. What changes is where the system runs and how it is licensed.

For many companies, that difference is the difference between “interesting AI operations tool” and “something we can actually evaluate for production.”

---

What Private Deployment Means

A private deployment runs ClowdOps as a dedicated appliance.

The agent, its disposable sandbox runtimes, the database, credentials, secrets, and operational history live on the box you control. Nothing routes through ClowdOps’ shared SaaS infrastructure for the agent’s day-to-day work.

The deployment still enrolls with Central, the ClowdOps licensing authority at platform.clowdops.ai, but Central is not in the path of your chats or infrastructure operations.

Central handles licensing and deployment accounting. It can mint a one-time registration voucher, issue a signed license, track deployment status, and receive aggregate usage totals needed for the license agreement.

It does not receive:

• Your chats.
• Your prompts.
• Agent outputs.
• AI provider keys.
• Cloud credentials.
• SMTP secrets.
• Database passwords.
• Infrastructure files.
• Data touched by the agent.

That boundary matters.

It makes ClowdOps useful for organizations that want agentic operations, but cannot accept a model where the operational surface of the company flows through a shared external platform.

---

Why Local Agent Operations Matter

AI agents are becoming part of the operating layer of software companies.

They inspect cloud accounts. They read dashboards. They generate cleanup plans. They summarize incidents. They reason about cost. They prepare migration steps. They call APIs. They run code in sandboxes. They coordinate across tools that used to require a human to jump between consoles.

That leverage is powerful, but it also raises the right questions:

• Where do credentials live?
• Which network can the agent reach?
• Which data leaves the company?
• Can the security team inspect the egress?
• Can a regulated team run the system in a specific geography?
• Can an internal estate use agents without exposing every child environment to the public internet?
• Can the company keep its own identity provider, login policy, backups, and operational controls?
• Can the agent help without becoming an uncontrolled automation surface?

Private deployment is the answer for teams that need those questions settled before they can move forward.

For startups, it means a stronger path to enterprise customers.

For agencies and cloud service providers, it means isolated deployments per client or per environment.

For infrastructure and platform teams, it means agentic operations can live closer to the systems being operated.

For security and governance teams, it means ClowdOps becomes inspectable, bounded, and deployable inside the organization’s own control model.

---

The Bigger Flashback Context

ClowdOps is not a standalone chatbot.

It is one part of Flashback’s broader agent-native network: a set of platforms and services built around governed AI, cloud operations, business intelligence, and controlled execution.

Flashgate focuses on access, routing, and infrastructure foundations. Bueeld helps founders and builders structure missions, progress, and execution. ClowdOps brings AI agents into company operations, beginning with cloud infrastructure through ClowdInfra and business intelligence through ClowdBI.

The private deployment work matters because it makes that agent network more realistic for organizations with serious operational constraints.

Some teams will use the hosted ClowdOps platform because speed and simplicity matter most.

Some teams will need a local appliance because privacy, residency, security, or customer requirements matter more.

Some larger estates will need both: a connected deployment for the main organization and child deployments for internal, segmented, or air-gapped environments.

That flexibility is the point. Agent-native operations should adapt to how a company is governed, not force every company into the same deployment shape.

---

The Deployment Model: Connected, Master, Child

The private deployment docs use three important words, but only two things are actually installed.

The first is a connected deployment.

This is the usual private setup. The box enrolls directly with Central, receives its signed license, reports health, and can use an automatic ClowdOps hostname like <label>.dply.clowdops.ai or a domain you bring yourself.

The second is a child.

A child deployment enrolls with one of your connected deployments instead of Central. This is useful for internal networks, segmented environments, or air-gapped estates where a box should talk only to your own master.

The word master describes a connected deployment once it has children.

So the model is:

Central (platform.clowdops.ai)
  -> Connected deployment / master
      -> Child deployment A
      -> Child deployment B

Most customers will only need connected deployments.

Masters and children are for larger environments where the architecture has to respect internal boundaries. A child reports to your master. Only the master talks to Central. For an air-gapped child, runtime operation can happen fully offline under a signed license, with reconciliation only when it can reach its authority again.

This is an important governance detail: Central does not need to hold a row for every child box in your internal estate. The master can roll up the child count and status so the organization stays within its license without exposing the internal topology in unnecessary detail.

---

What Stays Inside the Box

Private deployment is designed so customer data stays inside the customer’s perimeter.

The box only sends what is needed to license and account for the deployment:

• Enrollment and heartbeat: license status, health, appliance version, last-seen timestamp.
• Usage accounting: aggregate totals and counts for the licensing period, such as total spend, category breakdowns, model breakdowns, active users, and session counts.
• Estate roster for masters: child labels, statuses, versions, and last-seen timestamps, so deployment count stays accurate.

The important part is what does not leave.

Prompts stay local. Chat history stays local. Agent output stays local. Cloud credentials stay local. AI provider keys stay local. SMTP secrets, database passwords, infrastructure files, and operational data stay local.

For a security team, this creates a simpler review surface. The payload leaving the appliance is small, numeric, and licensing-oriented. The organization can inspect it and decide what egress is acceptable.

For regulated environments, this is the foundation of a better conversation: agentic operations without turning sensitive operational data into a shared-SaaS dependency.

---

Licensing Without Monthly Billing Inside the Box

Private deployments use a signed, offline-verifiable license.

The standard license validity is 365 days, renewed automatically while the box can reach its authority. The deployment also has a 21-day grace period if the authority becomes unreachable or the license lapses.

That grace model is practical.

The box does not suddenly shut down because of a temporary network cut. Instead:

1. A warning banner appears in the app.
2. After the grace period, new sessions are blocked.
3. Login and reads keep working.
4. Running chats are not killed.

Billing screens and Stripe subscription surfaces are disabled on the private deployment. Commercial terms live in the license agreement with ClowdOps, not in a self-service billing flow inside the product.

For enterprise buyers, that separation is useful. Procurement, licensing, and usage terms can be handled contractually, while the appliance stays focused on operations.

---

What Teams Get Locally

A private ClowdOps deployment is still ClowdOps.

Teams keep the core product capabilities:

• Projects to group related operational work.
• Sandboxes to isolate credentials, runtime scope, schedules, and history.
• Chat sessions for interactive agent work.
• Schedules for recurring prompts and unattended checks.
• Resources for discovered infrastructure context.
• Notifications for digests and alerts.
• Credentials entered in the UI and encrypted at rest.
• Guardrails to control which action categories are allowed.
• Cost caps at organization, project, sandbox, and chat levels.
• SSO through the organization’s own provider.
• Backups through S3-compatible storage or the organization’s own snapshot policy.

That combination is what makes the local deployment more than “run this agent script on a server.”

It gives a team an operating workspace: identity, execution, history, credentials, controls, schedules, budgets, and review paths in one place.

---

Safety: Credentials First, Guardrails Second

ClowdOps uses a two-layer safety model.

The first layer is the credential itself.

If the cloud credential attached to a sandbox is read-only, the agent cannot perform write actions beyond that permission boundary. No guardrail setting can grant more than the credential allows. This is the hard outer limit.

The second layer is ClowdOps guardrails.

Inside the credential boundary, the team controls mutating action categories such as:

• Modify data.
• Create resources.
• Delete data.
• Destroy resources.
• Scale capacity.
• Modify IAM permissions.
• Modify networking.
• Run commands on hosts.

Read access is implicit. Mutating categories require explicit grants. Interactive chats can require confirmation before a sensitive action proceeds. Scheduled runs are stricter because no human is present to approve them live.

Cost caps add the second axis of control: daily, monthly, and per-chat USD limits can stop runaway loops or expensive investigations before they become a surprise.

This matters even more in a private deployment. Running locally should not mean running without controls. The goal is governed autonomy: faster investigation, clearer plans, and bounded execution.

---

Prerequisites for a Private Deployment

The recommended host is simple, but it should be dedicated.

The ClowdOps appliance expects a fresh Linux/amd64 VPS. Do not co-locate it with unrelated workloads, because the agent uses disposable sandbox containers and the box is designed to own its runtime environment.

Minimum and recommended sizing:

• Architecture: linux/amd64. ARM is not supported.
• vCPU: 2 minimum, 4+ recommended.
• RAM: 8 GB minimum, 16 GB+ recommended.
• Disk: 25 GB minimum, 40 GB+ recommended.
• OS: modern Linux with Docker support, with Ubuntu 22.04 or Debian 12 recommended.
• Inbound ports: 80 and 443.
• Outbound connectivity: Central, container registries, and the AI/cloud APIs the agents need, unless running an air-gapped child.
• Access: root or sudo.
• Registration: an install command generated by an organization admin from the ClowdOps portal.

The disk note is important. Sandbox runtime images are large, roughly several GB each. If bandwidth or disk is limited, the installer can pre-warm fewer images, such as only the chat runtime, or none at install time.

---

Tutorial: The Setup Flow

The private deployment flow is split between two roles.

An organization admin registers the deployment in the ClowdOps portal.

A sysadmin provisions the host and runs the installer.

That division is intentional. It keeps licensing and organization ownership in the portal, while keeping infrastructure bring-up in the hands of the person who controls the server.

Step 1: Register the Deployment

In the hosted ClowdOps portal, an organization admin goes to:

Settings -> Deployments -> Register deployment

The registration form asks for:

• A short deployment label, such as paris-dc1.
• A hostname mode: automatic ClowdOps DNS or bring-your-own domain.
• A founding admin email.
• Optional user propagation from the current organization.
• Optional child-facing authority URL if this deployment will become a master for internal children.

When the admin clicks Register, Central reserves a deployment slot and mints a one-time voucher.

The portal shows an install command like:

curl -fsSL https://platform.clowdops.ai/install.sh | sudo bash -s -- --token=<voucher>

The voucher is shown once and expires after 72 hours. If it expires, register again and generate a fresh command.

Step 2: Prepare the Host

Provision a fresh Linux/amd64 VPS.

Open inbound ports 80 and 443.

If you bring your own hostname, create the DNS A record before installation so TLS can be issued on first boot.

If you use the automatic hostname, Central can allocate <label>.dply.clowdops.ai and point it at the deployment during enrollment.

Step 3: Run the Guided Setup

The newest docs recommend the guided setup script for most installs.

On the box, as root:

curl -fsSLO https://raw.githubusercontent.com/clowdops/product-guides/main/cloud-agent/private-deployment/setup.sh
chmod +x setup.sh
sudo ./setup.sh

The script does not replace the Central installer. It wraps it.

It walks the sysadmin through the decisions that used to be more manual:

• Paste the full install command or the fbd_... voucher.
• Confirm the role discovered from the voucher.
• Confirm the hostname.
• Choose sandbox images to pre-warm.
• Configure SSO providers.
• Choose invite-only or open registration.
• Configure SMTP if needed.
• Configure S3-compatible off-box backups if needed.

For SSO, the script can guide Google, Microsoft, GitHub, or generic OIDC. It prints the exact redirect URL to register with the identity provider and writes the values into the appliance’s operator configuration.

For air-gapped children, it steers the operator toward an in-network OIDC provider, because public Google, Microsoft, or GitHub sign-in requires outbound internet from the box.

Step 4: Or Run the Installer Directly

Teams that prefer the manual path can paste the portal command directly:

curl -fsSL https://platform.clowdops.ai/install.sh | sudo bash -s -- --token=<voucher>

The installer:

1. Checks host requirements.
2. Installs Docker if needed.
3. Decodes the voucher.
4. Downloads the appliance bundle.
5. Writes environment values.
6. Generates secrets and cryptographic keys.
7. Starts the Docker Compose stack.
8. Applies database migrations.
9. Self-enrolls with the authority.
10. Receives the signed license.
11. Starts heartbeating.
12. Lets Caddy obtain a TLS certificate.

The installer is idempotent, so it can be rerun safely for updates.

Step 5: Verify Enrollment

In the portal, the deployment should move:

registered -> enrolled -> active

On the box, the sysadmin can inspect backend logs for federation and heartbeat messages:

docker logs clowd-backend-server 2>&1 | grep -i federation

The signed license is stored on disk:

sudo cat /etc/clowd/secrets/federation/license.json

Step 6: Claim the Founding Admin

Once healthy, the founding admin account is claimed either through the portal’s one-time set-password link or by running the bootstrap command printed by the installer.

For a manual path:

cd /opt/clowd/deploy/topologies/appliance
docker compose --profile bootstrap run --rm admin-init \
    --email you@acme.example --first-name You --last-name Admin

The temporary password should be rotated immediately.

Step 7: Back Up the Irreplaceable Parts

This step is not optional in practice.

Back up these off-box:

• /etc/clowd/secrets/keys
• /etc/clowd/secrets/federation
• /etc/clowd/secrets/env/auto.env
• The caddy-data Docker volume.
• The application database through S3 backups or the organization’s snapshot policy.

The master encryption key protects encrypted credentials and secrets. If it is lost, encrypted data cannot be recovered.

The federation directory contains the deployment identity and signed license. On a master, it also contains the delegation needed to sign child licenses. Losing it can force re-enrollment and, for a master, re-enrollment of children.

---

SSO and Login Policy

Private deployments support email and password out of the box.

For production use, most companies will connect their own identity provider.

Because the appliance runs on the customer’s own domain, it cannot reuse ClowdOps’ shared SaaS OAuth clients. The customer registers its own provider app and gives the appliance the client ID and secret.

Supported paths include:

• Google OAuth.
• Microsoft Entra ID.
• GitHub OAuth.
• Generic OIDC for providers such as Okta, Auth0, Entra ID, Keycloak, or Ping.

The redirect URL follows a simple pattern:

https://<your-domain>/auth/<provider>/callback

Examples:

• https://clowd.acme.example/auth/google/callback
• https://clowd.acme.example/auth/microsoft/callback
• https://clowd.acme.example/auth/github/callback
• https://clowd.acme.example/auth/oidc/callback

Client secrets stay in operator.env on the box. They are used server-side and never sent to the browser.

The recommended private pattern is invite-only:

1. Invite or provision users first.
2. Let them sign in with SSO.
3. Match them by verified email address.

Open registration can be enabled, but private deployments will usually keep OPEN_REGISTRATION=false so unknown SSO users cannot create their own accounts.

Password login can be disabled later with PASSWORD_LOGIN=false, but only after SSO has been verified end to end with an admin account. The docs intentionally keep password sign-in available on first install so teams do not lock themselves out.

---

Credentials and AI Keys

Cloud credentials and AI provider keys are not environment variables on a private deployment.

They are entered in the app UI, scoped to the organization and sandbox, encrypted at rest, and kept inside the box.

This preserves the same operational model as hosted ClowdOps while changing the deployment boundary:

• The team can attach AWS, GCP, Azure, OCI, SSH, GitHub, GitLab, Azure DevOps, notification, or other operational credentials.
• The team can bring its own AI provider keys, such as OpenAI, Anthropic, Gemini, or AWS Bedrock, according to its own policies.
• The agent uses those credentials inside the sandbox and guardrail model.
• Credentials remain bounded by the permissions the organization chose.

This is where private deployment becomes powerful for governance.

Security can review the credential scopes, network egress, identity provider, backup policy, and ClowdOps guardrails as one integrated operating model.

---

Operational Examples

Private ClowdOps is especially relevant for teams that want AI operations but cannot expose their operational layer broadly.

Example 1: A regulated company running cloud cost reviews.

The team deploys ClowdOps on a controlled VPS in its required region. It attaches read-only plus billing credentials for cloud accounts. A weekly scheduled run identifies cost changes, idle resources, and ownership gaps. The output stays inside the appliance. Finance and platform teams review the digest without giving a third-party SaaS direct access to the company’s operational data.

Example 2: A cloud service provider managing client estates.

The provider runs isolated private deployments per sensitive client or per geography. Each deployment has its own SSO, credentials, backups, guardrails, and schedules. The provider can standardize workflows while respecting client boundaries.

Example 3: An internal network with child deployments.

A connected master talks to Central and serves as the licensing authority for internal children. The children talk only to the master. Air-gapped children can run under signed licenses and reconcile when allowed. The organization gets the benefits of agentic operations while keeping segmented environments segmented.

Example 4: A platform team preparing migration cleanup.

The team connects read-only infrastructure credentials first. It asks ClowdOps to inventory active resources, identify likely unused workloads, map cost centers, and prepare a migration readiness plan. Mutating categories remain ungranted until the team is ready for reviewed execution.

---

What This Unlocks

The private setup makes ClowdOps more useful for serious company operations because it aligns with how enterprises already think:

• Privacy: operational data and credentials stay in the customer’s environment.
• Governance: identity, login policy, SSO, registration, and user provisioning can match company rules.
• Security: egress is narrow, inspectable, and licensing-oriented.
• Sovereignty: teams can place the appliance in the region or infrastructure they control.
• Segmentation: master-child federation supports internal and air-gapped estates.
• Continuity: signed licenses and grace periods avoid brittle runtime dependency on Central.
• Auditability: chats, schedules, history, resources, and controlled actions remain inside the operating workspace.
• Cost control: budgets and per-chat caps reduce runaway execution risk.
• Operational leverage: agents can investigate, summarize, schedule, and plan without turning every workflow into custom internal tooling.

This is the direction ClowdOps has been moving toward from the beginning.

The point is not to replace engineers or give an agent unlimited access to production.

The point is to make strong teams faster inside a control model they can trust.

---

Where to Start

If you want to evaluate private deployment, start with the official ClowdOps product guides:

Private deployment guide: https://github.com/clowdops/product-guides/blob/main/cloud-agent/private-deployment/README.md

Install the appliance: https://github.com/clowdops/product-guides/blob/main/cloud-agent/private-deployment/install-the-appliance.md

Credential setup recipes: https://github.com/clowdops/product-guides/blob/main/cloud-agent/credentials/README.md

Guardrails and cost caps: https://github.com/clowdops/product-guides/blob/main/cloud-agent/guardrails.md

Explore ClowdOps: https://clowdops.ai/

The recommended first pilot is simple:

1. Start with a connected private deployment.
2. Use a fresh Linux/amd64 VPS with 16 GB RAM and 40 GB disk if possible.
3. Keep credentials read-only for the first sandbox.
4. Configure SSO only after the founding admin can log in.
5. Add SMTP and off-box backups before inviting a wider team.
6. Run a first scheduled cloud inventory or cost review.
7. Tighten guardrails and budgets before enabling any mutating workflow.

That is enough to test the real value: can ClowdOps help your team understand, prioritize, and govern cloud operations faster while keeping the operational layer under your control?

For many organizations, private deployment is the missing piece.

It turns ClowdOps from a promising agent platform into an agent-native operations layer that can live where the company already lives: inside its own infrastructure, its own identity model, and its own rules.

Talk to your cloud. Locally, privately, and with control.