Cloud endpoints
A cloud endpoint is created in the dashboard and stays online with no agent running anywhere. It is a URL plus a Traffic Policy, and the policy is the whole of what it does. Edit the policy and the change applies within seconds, with no restart and no dropped requests.
Creating one
In the dashboard, open Endpoints → New Endpoint and pick Forward to an internal endpoint, Redirect to another URL, Return a custom response, or Something custom → Cloud Endpoint. Choose a URL on one of your domains (or an internal one), pick a starting policy, edit it, and create the endpoint.
A stable front door
The usual setup: the public URL is a cloud endpoint, and the services behind it are internal agent endpoints.
on_http_request:
- name: Api
expressions:
- "req.url.path.startsWith('/api')"
actions:
- type: forward-internal
config:
url: https://api.example.internal
- name: Everything else
actions:
- type: forward-internal
config:
url: https://web.example.internal
on_error: continue
- type: custom-response
config:
status_code: 503
body: We'll be right back.
Agents run devgate http 3000 --url https://api.example.internal and
devgate http 8080 --url https://web.example.internal; restart them, move them between machines, or pool
several — the public URL never changes behaviour.
Billing
A cloud endpoint counts toward your plan’s online endpoints while it is enabled, and its active hours — hours in which it served traffic — are billed like any endpoint’s, except on your dev domain, where they’re free.
Questions people actually ask
A cloud endpoint has no agent behind it, so there is nowhere to send a request the policy didn’t answer. A rule without expressions ending in forward-internal, custom-response, redirect or deny guarantees every request gets an answer; one that slips through gets a 503.
Yes. The cloud endpoint takes the URL’s traffic, as on ngrok — which is the point: keep the public URL on a cloud endpoint and forward to agent endpoints that come and go.