Cloud 66 API

Name: Cloud 66 API API
Brand: Cloud 66 API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsCi Cdoauth225 EndpointsREST

For Agents

Trigger deployments, reboot servers, manage environment variables, and inspect stacks across Cloud 66-managed applications.

Connect the Cloud 66 API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Cloud 66 API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Cloud 66 API API.

List and create stacks that represent application deployments across cloud providers

Trigger redeploys and other lifecycle actions against an existing stack

Read and update environment variables for a stack without redeploying

Reboot individual servers or all servers in a stack

GET STARTED

Start building with Cloud 66 API API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for Cloud 66 API, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for Cloud 66 API, keeping it validated and agent-ready. Cloud 66 is a DevOps-as-a-Service platform that deploys and manages applications on any cloud provider. The v3 API exposes stacks (the unit of an application deployment), servers under those stacks, services and containers, deployments, environment variables, settings, backups, firewalls, actions, notifications, and account-level data, so an integration can drive a full deploy-and-operate workflow against an existing Cloud 66 account.

Use Cases

Patterns agents use Cloud 66 API API for, with concrete tasks.

★ ChatOps Deploy Triggers

Trigger Cloud 66 deployments from a chat command or pull-request merge by calling POST /stacks/{stack_uid}/deployments.json. The endpoint kicks off the standard Cloud 66 deploy pipeline against the target stack, which removes the need for engineers to log into the Cloud 66 dashboard for routine releases. Combined with /stacks/{stack_uid}/notifications, the same workflow can post deploy results back into the chat channel.

Call POST /stacks/{stack_uid}/deployments.json for the production stack and poll until the deployment completes

Auto-Healing and Restart Workflows

Build an auto-heal loop that detects failing services and reboots the underlying server or removes a stuck container. POST /stacks/{stack_uid}/servers/{server_uid}/reboot_server.json triggers a single-server reboot, POST /stacks/{stack_uid}/reboot_servers.json reboots the entire stack, and DELETE /stacks/{stack_uid}/containers/{container_uid}.json removes a problematic container. This pattern replaces ad-hoc SSH access for routine recovery actions.

If a stack reports a failing container, call DELETE /stacks/{stack_uid}/containers/{container_uid}.json then poll /stacks/{stack_uid}/containers.json until a replacement is healthy

Configuration Drift Management

Sync environment variables and stack settings into Cloud 66 from a central config store so that drift between environments is eliminated. PUT /stacks/{stack_uid}/environments/{key}.json updates a single env var without redeploying, and GET /stacks/{stack_uid}/settings.json plus PUT /stacks/{stack_uid}/settings/{key}.json manage stack-level configuration. This is the standard pattern for keeping staging and production aligned.

Read env vars from a source-of-truth file and PUT /stacks/{stack_uid}/environments/{key}.json for each that differs

Observability and Backup Audits

Pull the list of backups, server inventory, and notifications across an account into a central observability tool. GET /stacks/{stack_uid}/backups.json, GET /stacks/{stack_uid}/servers.json, and GET /stacks/{stack_uid}/notifications give enough surface to drive a backup-coverage report and an inventory dashboard for compliance reviews.

Iterate stacks via GET /stacks.json, then call GET /stacks/{stack_uid}/backups.json for each and report stacks with no backup in the past 24 hours

Agent-Driven Deploy Workflows via Jentic

AI deployment assistants discover Cloud 66 operations through a Jentic search like 'redeploy my stack' and execute the call without parsing Cloud 66's REST docs. Jentic stores the OAuth token and issues a scoped credential per call that respects the requested scope (public, redeploy, jobs, admin), which keeps long-lived tokens out of agent context.

Search Jentic for 'redeploy cloud 66 stack', load POST /stacks/{stack_uid}/deployments.json, and execute it for the user-specified stack

Key Endpoints

25 endpoints — jentic publishes the only available openapi specification for cloud 66 api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/stacks.json

List stacks in the account

POST

/stacks

Create a stack

POST

/stacks/{stack_uid}/deployments.json

Trigger a deployment

PUT

/stacks/{stack_uid}/environments/{key}.json

Update an environment variable

POST

/stacks/{stack_uid}/servers/{server_uid}/reboot_server.json

Reboot a server

GET

/stacks/{stack_uid}/containers.json

List containers on a stack

GET

/stacks/{stack_uid}/backups.json

List backups for a stack

POST

/stacks/{stack_uid}/actions.json

Trigger a stack action

GET

/stacks.json

List stacks in the account

POST

/stacks

Create a stack

POST

/stacks/{stack_uid}/deployments.json

Trigger a deployment

PUT

/stacks/{stack_uid}/environments/{key}.json

Update an environment variable

POST

/stacks/{stack_uid}/servers/{server_uid}/reboot_server.json

Reboot a server

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Cloud 66 OAuth tokens are stored encrypted in the Jentic vault. Agents receive a per-call scoped access token that respects the requested scope (public, redeploy, jobs, admin), so long-lived tokens never enter the agent's context or logs.

Intent-based discovery

Agents search Jentic with intents like 'redeploy stack' or 'reboot server' and Jentic returns the matching Cloud 66 operation with its input schema, removing the need to crawl developers.cloud66.com.

Time to first call

Direct Cloud 66 integration: 1-2 days for OAuth registration, scope handling, and token refresh. Through Jentic: under 30 minutes — search, load, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

Render

Modern PaaS for deploying web services, static sites, and background workers.

Choose Render when starting greenfield without an existing cloud account; use Cloud 66 when deploying onto AWS/GCP/Azure infrastructure already owned.

Alternative

DigitalOcean

Cloud provider with App Platform, droplets, and Kubernetes.

Choose DigitalOcean when the team wants a single-vendor cloud relationship rather than Cloud 66's multi-cloud orchestration.

Complementary

Netlify

Front-end hosting with Git-driven build pipelines.

Use Netlify for the static front end while Cloud 66 manages the back-end stacks across cloud accounts.

FAQs

Specific to using Cloud 66 API API through Jentic.

Why is there no official OpenAPI spec for Cloud 66 API?

Cloud 66 does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Cloud 66 API via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the Cloud 66 API use?

Cloud 66 uses OAuth 2.0 authorization-code flow with four scopes — public (read-only), redeploy (trigger deployments), jobs (manage jobs), and admin (full access). Through Jentic, the OAuth token is held in the vault and a scoped access token is issued per call so the raw token never enters the agent's context.

Can I trigger a redeploy of a stack with this API?

Yes. POST /stacks/{stack_uid}/deployments.json kicks off a Cloud 66 deployment against the target stack, and the redeploy scope is the minimum scope required. Combine with GET /stacks/{stack_uid}.json to poll for deployment status.

What are the rate limits for the Cloud 66 API?

Cloud 66 does not document a strict rate limit in this spec. Treat the API as low-volume control-plane traffic — back off on 429 responses and avoid bursting more than a few requests per second per OAuth token.

How do I reboot a single server in a stack through Jentic?

Run pip install jentic, search for 'reboot cloud 66 server', load the POST /stacks/{stack_uid}/servers/{server_uid}/reboot_server.json operation, then execute with the stack_uid and server_uid. The call returns the action status.

Can I update environment variables without redeploying?

Yes. PUT /stacks/{stack_uid}/environments/{key}.json updates a single environment variable on a stack and does not force a redeploy on its own. Use POST /stacks/{stack_uid}/deployments.json afterwards if the running app needs the new value.