ce.sh

The continuous.engineering connect tool: fuzzy-find and SSM-connect to any onboarded client's cloud resources, with a locally cached inventory that stays fast across dozens of clients.

For continuous.engineering engineers only. Clients granting us access should see Deploy on AWS instead.

---

curl -fsSL https://grant-access.continuous.engineering/install.sh | bash

Installs ce to ~/.local/bin/ce, checks dependencies, prints next steps.

To update later, either re-run the command above or use ce update (lighter - just re-fetches ce, no dependency re-check; idempotent, so it's a no-op if nothing changed).

---

Then

ce setup              # verify dependencies
ce login               # SSO device-code login (needed on SSH/headless hosts
                        # with no local browser - ce connect/list trigger this
                        # automatically too, but ce login lets you go first)
ce set client <name>  # after a CE admin has run ce onboard for that client
ce connect <text>      # fuzzy-pick and connect

ce connect fuzzy-matches a client and instance name/state/type/tags, in any order, filling in whatever you haven't typed from your saved defaults. Region isn't a separate thing you resolve first - it's just another column in the same fuzzy-searchable row, right alongside provider, name, and tags, so a query like orlando lut finds the right instance regardless of which region it's actually in. Exactly one match connects immediately, no picker needed.

Results are cached per client+region and refresh in the background, so the picker always renders instantly.

Just want to see what's there without connecting? ce list <client> [filter text] - cache-first, only blocks on a live AWS/GCP/Azure call if the cache is over an hour old (CE_CACHE_TTL_SECONDS to change that) or you pass --force. Same fuzzy filtering as ce connect (ranked, not a strict match - shows the best hits first rather than hiding everything else), just prints a table instead of connecting. Only running instances show by default (whitelisted, not just stopped ones blacklisted - terminated/stopping/deallocated etc. are equally irrelevant to a quick scan) - --all drops the filter. Table is deliberately narrow: name, region, tags. State only shows with --all (pointless printing "running" on every row when that's true by construction); instance size and private IP are dropped from the table entirely, though both are still in the underlying cache and in ce connect's picker if you need them.

AWS instance lists are always per-region - there's no "every instance in this account" API, so ce list/ce connect merge across every region a client has instances in rather than searching just one. If you don't know which region(s) a client is actually running in, ce regions [client] [--save] scans every region CE knows about and, with --save, stores the active ones - client is optional here too, same default-client fallback as ce list/ce connect.

--force and --refresh are interchangeable everywhere they apply (ce list, ce connect) - use whichever reads better to you.

---

Prerequisites

aws cli, gcloud cli, az cli, session-manager-plugin, jq, fzf. Run ce setup any time to see what's missing, and ce setup --install to install everything missing in one step. It asks once before doing anything, and --yes skips the prompt for scripted setups. aws, session-manager-plugin and gcloud install under ~/.local with no sudo; jq, fzf and az use your OS package manager (apt, dnf or brew) and need sudo on Linux. If a command finds a dependency missing in an interactive terminal, it offers to run the install for you.

Getting a client registered

Your local ~/.config/continuous.engineering/clients.json is never shared or synced: a CE admin running ce onboard for a client registers it in your registry automatically, for any provider (--provider aws|gcp|azure|local). See AWS, GCP, and Azure for each cloud's deploy flow; Azure additionally needs the engineer roster kept current via ce-azure-roster.sh.

For AWS, onboarding writes one ~/.aws/config profile per tier (client-<name>-readonly through client-<name>-admin) rather than a single fixed role - ce set tier <t> picks which one ce list/ce connect/ce aws actually resolve to, once, instead of a flag on every call. Clients onboarded before this existed only have the old single CE-DevOps profile until you re-run ce onboard for them (safe to re-run, idempotent).

--provider local is a different kind of client entirely - no cloud account, no trust to set up, no live inventory API. It's plain SSH: ce list/ce connect/ce_run read whatever Host blocks already exist in ~/.ssh/config (including anything pulled in via Include) as the instance list, connect with ssh <alias> directly, and run commands with ssh <alias> "<command>" - no region concept, no login step (your own SSH keys/agent/ProxyJump chain does whatever it already does). ce onboard --name local --provider local registers it; there's nothing further to configure - add/edit Host blocks the same way you always would.

Command reference

Command	Does
ce setup [--install [--yes]]	Check dependencies, show current config; --install installs anything missing
ce login [profile]	SSO device-code login (default profile: continuous-admin)
ce set client|region|tier <value> / ce unset	Set or clear a default. tier picks which AWS role every client resolves to (readonly/security/sre/devops/data/admin/billing/support, default devops) - saved once, not chosen per call
ce show	Defaults, CE profile session status, and every known client (account/project/subscription, regions, live session status)
ce accounts	Flat table of every registered client - account/project/subscription id, regions, AWS tier profiles
ce connect [tokens...]	Fuzzy-pick and connect across all regions (--refresh/--force, -c <name>, --tier for GCP)
ce list [client] [filter text]	List instances without connecting (--force to bypass the 1h cache)
ce regions [client] [--save]	Scan all AWS regions for instances, optionally save the active ones
ce onboard --name <n> --account <id> [--provider aws|gcp|azure|local] [--remove]	Register a new client (both sides of the AWS trust, profile, local registry). --provider local needs no --account
ce commands [sync]	List (or refresh) the named-command library used by -c
ce update	Re-fetch ce from the same source install.sh uses
ce aws <client> -- <args>	Any aws-cli command through the client's resolved profile - e.g. ce aws orlando -- s3 ls
ce gcp <client> [--tier T] -- <args>	Same for gcloud
ce az <client> -- <args>	Same for az

---

MCP

ce-mcp-server exposes ce as MCP tools - ce_list, ce_regions, ce_show, ce_accounts, ce_run (the non-interactive form of ce connect ... -c, since an MCP tool call has no TTY for the interactive picker - target must resolve to exactly one instance or the call fails cleanly), ce_aws, ce_gcp, ce_az, ce_commands. It's a thin wrapper - every tool just shells out to your already-installed ce, so it inherits the same trust chain, session handling, and profile/tier resolution, nothing reimplemented.

Every named command in the ops-commands library also gets its own real MCP tool at startup (ce_cmd_docker_ps, ce_cmd_sys_disk, ce_cmd_docker_logs, ...) - registered from ce commands --json, with the command's real description and, for any __PLACEHOLDER__ fill-ins (ce_cmd_docker_logs's CONTAINER, ce_cmd_net_check's HOST/PORT, etc.), a proper required input field instead of ad-hoc KEY=value text you'd have to know to append. ce_run with a free-text command argument still works too - the per-command tools are additive, not a replacement.

curl -fsSL https://grant-access.continuous.engineering/install-mcp.sh | bash

Installs to ~/.local/share/continuous.engineering/mcp (its own npm install, isolated from anything else) with a thin executable wrapper at ~/.local/bin/ce-mcp-server. Requires ce itself already installed and Node.js 18+.

Register with Claude Code:

claude mcp add ce -- ~/.local/bin/ce-mcp-server

Register with Claude Desktop or any other MCP client by adding it to that client's config:

{"mcpServers": {"ce": {"command": "/home/you/.local/bin/ce-mcp-server"}}}

ce_run and the cloud-CLI passthrough tools (ce_aws/ce_gcp/ce_az) can run arbitrary commands against any client you're onboarded to - same privilege you already have in your own shell via ce connect ... -c/ce aws ..., just reachable as a tool call instead of something you type and see before it runs. Worth being deliberate about which MCP clients you register this with.

---

Questions: devops@continuous.engineering