canonical: https://jentic.com/apis/localops.co/localops

# LocalOps API

The LocalOps API deploys and manages services inside LocalOps environments running on your own cloud connection. You create web, internal, worker, cron, or job services from GitHub, GitLab, a Docker image, or a Helm chart, size their replicas, CPU, and memory, trigger deployments, and poll deployment and service state, since deploys, deletes, and secret writes are accepted asynchronously. It also adds and verifies custom domains for a service and replaces environment-level and service-level secrets. A few endpoints, such as environment creation and operation logs, are published ahead of release and return 404 today.

## For AI agents

Create and deploy LocalOps services from GitHub, GitLab, Docker images, or Helm charts, check deployment and service status, add and verify custom domains, and replace environment or service secrets.

## Scope

Does not host source code, run CI test pipelines, or register domain names. Use for deploying and managing services, custom domains, and secrets in LocalOps environments only.

## Capabilities

- Create a web, internal, worker, cron, or job service in an environment from a github, gitlab, docker_image, or helm_chart source
- Trigger a deployment of a service with deployService and poll getDeployment for the outcome
- Scale a service by updating replica_count, cpu_count_min, cpu_count_max, memory_mb_min, and memory_mb_max
- Change a service's git_repo_branch, run_command, dockerfile_path, or auto_deploy setting with updateService
- Add a custom domain to a service, verify it, and force-deploy its configuration
- Read and replace environment-level and service-level secrets with replaceEnvironmentSecrets and replaceServiceSecrets

## Use cases

### Agent-driven deploys through Jentic

A coding agent that has merged a change asks Jentic for the LocalOps deploy operation, calls deployService for the environment and service, then polls getDeployment until the asynchronous deploy settles. The account API token, which owners and admins read from the LocalOps console, stays in your self-hosted Jentic One instance.

Example prompt: Search Jentic for 'deploy a LocalOps service', call deployService with envId and serviceId for the backend service, then poll getDeployment with the returned deployment id until it finishes

### Service creation from a repository

Create a new service with createService, giving it a name, a source such as github or docker_image, a type such as web with its port, and the replica, CPU, and memory sizing required for non-Helm sources. Set deploy_now to trigger the first deployment immediately, and is_protected to block deletion until protection is removed.

Example prompt: Call createService in envId 'env-123' with name 'Billing Worker', type 'worker', source 'github', replica_count 2, cpu_count_min 0.5, memory_mb_min 512, and deploy_now true

### Custom domains for web services

Attach a domain with addCustomDomain, read its state with getCustomDomains, and call verifyCustomDomain once DNS is in place. forceDeployCustomDomain re-applies the domain configuration, and the outcome is observed by polling custom domain state because these calls are asynchronous.

Example prompt: Call addCustomDomain for the web service with domain 'app.example.org', then call verifyCustomDomain with the returned customDomainId

### Secret rotation

Rotate credentials by reading current keys with getEnvironmentSecrets or getServiceSecrets and writing the full new set with replaceEnvironmentSecrets or replaceServiceSecrets. Secret writes are asynchronous, so a follow-up check of service state confirms they landed.

Example prompt: Call getServiceSecrets for the backend service, then call replaceServiceSecrets with the same set plus the new DATABASE_PASSWORD value

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/v1/environments/{envId}/services` | Create a service |
| GET | `/v1/environments/{envId}/services/{serviceId}` | Get service status |
| PATCH | `/v1/environments/{envId}/services/{serviceId}` | Update a service |
| POST | `/v1/environments/{envId}/services/{serviceId}/deploy` | Deploy a service |
| GET | `/v1/deployments/{deploymentId}` | Get a deployment |
| POST | `/v1/environments/{envId}/services/{serviceId}/custom-domains` | Add a custom domain |
| PUT | `/v1/environments/{envId}/secrets` | Replace environment secrets |

## Key resources

- **Environments** — LocalOps environments in your cloud connection and region
- **Services** — Web, internal, worker, cron, and job workloads with sizing and source
- **Deployments** — Asynchronous deploys whose state you poll
- **Custom domains** — Domains attached to a service with verification state
- **Secrets** — Environment-level and service-level secret sets

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 70 / 100
- **Maturity:** AI-Aware
- **Dimensions:**
  - Foundational Compliance: 83 / 100
  - Developer Experience & Jentic Compatibility: 69 / 100
  - AI-Readiness & Agent Experience: 55 / 100
  - Agent Usability: 94 / 100
  - Security: 60 / 100
  - AI Discoverability: 77 / 100
- **View full report:** https://jentic.com/apis/localops.co/localops/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring LocalOps by hand means attaching its account bearer token, unwrapping the message and data response envelope, and polling deployment and service state because deploys and secret writes return before they finish. Through Jentic you install once, import LocalOps from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** LocalOps puts envId and serviceId in the URL path, so a rule can pin your agent to one environment: it can deploy and inspect services under `/v1/environments/{envId}`/ for that environment and nothing else. You choose the operations it may call, so destructive ones like deleteService or replaceEnvironmentSecrets are not included unless you add them.
- **Credential handling:** Your LocalOps API token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'deploy a service' or 'add a custom domain', and Jentic returns the matching LocalOps operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Render API** — Managed hosting for web services, workers, and cron jobs
- **Railway API** — Hosted deployment platform with services and environments
- **Vercel API** — Frontend and serverless deployments with domains
- **GitHub API** — Source repositories that LocalOps services deploy from

## FAQ

### What authentication does the LocalOps API use?

Per its OpenAPI spec, the LocalOps API uses an HTTP bearer scheme carrying your account API token, a UUID that owners and admins read from the LocalOps console, sent as `Authorization: Bearer`. GET /health needs no token. Through Jentic the token is stored encrypted by your own Jentic One instance and injected at call time.

### How do I know whether a LocalOps deploy succeeded?

Deploys are asynchronous: a 2xx from POST `/v1/environments/{envId}/services/{serviceId}/deploy` only confirms the request was accepted and passed validation. Poll GET `/v1/deployments/{deploymentId}` for deployment state, or GET `/v1/environments/{envId}/services/{serviceId}` for service state, to see the outcome.

### What are the rate limits for the LocalOps API?

The OpenAPI spec does not specify rate limits. Check the LocalOps documentation at docs.localops.co for current limits, and poll deployment state at a modest interval.

### How do I deploy a service with the LocalOps API through Jentic?

Install Jentic One with `curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh`, add the LocalOps API from the Jentic API Directory, and have your agent search for 'deploy a LocalOps service'. Jentic returns deployService (POST `/v1/environments/{envId}/services/{serviceId}/deploy`) with its schema, and the agent passes envId and serviceId. To run it on your own infrastructure, install Jentic One from its GitHub repo.

### Is there a LocalOps MCP server?

You don't need an MCP server to give your agent the LocalOps API. Jentic connects it directly from the API Directory: import it, store your credential once, and your agent calls it, with operations discovered on demand instead of loading extra tool definitions into its context.

### Can I limit what my agent is allowed to do with the LocalOps API?

Yes. Write a rule that allows deployService and getServiceStatus only under `/v1/environments/env-staging`/, plus getDeployment. The agent can then ship and check services in staging alone, while production, deleteService, and the secret-replacement calls stay outside its reach, and every call it makes is logged.

### Which service sources and types does the LocalOps API support?

createService accepts a source of github, gitlab, docker_image, or helm_chart, and a type of web, internal, worker, cron, or job. A port is required for web and internal services, cron_schedule for cron services, and replica, CPU, and memory sizing unless the source is helm_chart.