Install Jentic One Beta

Connect the LocalOps API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the LocalOps 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.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Flocalops.co%2Flocalops" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Flocalops.co%2Flocalops" | 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 LocalOps API.

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

GET STARTED

Start building with LocalOps API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use LocalOps API for, with concrete tasks.

★ 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.

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.

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.

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.

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

Key Endpoints

22 endpoints — the localops api deploys and manages services inside localops environments running on your own cloud connection.

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

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

Why Jentic?

What agents get from Jentic-routed access to this vendor.

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 isolation

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.

Intent-based discovery

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.

FAQs

Specific to using LocalOps API through Jentic.

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.

LocalOps API

AI ReadinessAI-Aware (B+)70/100

See full scorecard

Official vendor OpenAPI document · agent-readyCloud InfrastructureContainer Orchestrationhttp bearer (account API token)22 EndpointsREST

For 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.

Use for: Deploy the latest build of the backend service in staging, Check whether the deployment I just started succeeded, Scale the worker service to three replicas, I want to add a cron service that runs nightly

Not supported: 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.

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.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: ASignals: 4

98%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

100%

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

35%

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: B+Signals: 4

Example Density

How richly the API is illustrated with examples.

97%

Example Validity

Percentage of examples that conform to their schemas.

73%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

100%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: CSignals: 4

52%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

100%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

67%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: B-Signals: 1

60%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: A-Signals: 1

77%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the LocalOps API to your agent

Capabilities

Start building with LocalOps API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

LocalOps API

Jentic AI Readiness Score

LocalOps API

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness