Questions and limitations

Does it work on an air-gapped network?

No. The agent needs outbound HTTPS on port 443 to blueprintr.io and agents.blueprintr.io. Every job comes from Blueprintr and every result goes back to it, so there is no offline mode and nothing is stored locally to upload later. It suits private and firewalled networks: nothing connects inward, so no inbound rule is needed.

Can it go through our proxy?

Yes, for its traffic to Blueprintr. Set proxy and noProxy in config.json, or HTTPS_PROXY and NO_PROXY in the agent's environment. Connections to your own systems and SNMP sweeps never use the proxy. For a proxy that inspects TLS, give the agent the proxy's root certificate as extraCaFile, which it trusts for Blueprintr only. If the proxy blocks the WebSocket to agents.blueprintr.io, the agent polls instead.

Where are our credentials stored?

On the agent's host, in the places listed under Where credentials are kept. Credentials you configure are in config.json, or in the environment variables and files it refers to, or in a credentialFile your secret manager writes. Credentials sent from Blueprintr, which is off unless you set allowRemoteCredentials, are written to the agent's state directory. Blueprintr stores none of them, and for credentials in config.json it never receives the value.

Where is our data stored?

The agent sends Blueprintr its own status, the answers to the jobs it runs and its sweep results. Blueprintr keeps its records of agents, relay jobs, saved panels and sweeps in its application database, and What Blueprintr stores says what each record contains, who can see it and how long it is kept. Blueprintr's privacy policy places the application and its database in Amazon Web Services in Ireland (eu-west-1), with Cloudflare in front of it.

Can we run several agents, or one per site?

Yes. An organisation or team can have up to 25 agents, each with its own name, configuration and discovery ranges. Revoked agents count towards that until you delete them. Put each site's systems in the configuration of the agent at that site.

Each agent reports the integration IDs in its configuration, and those sent to it from Blueprintr. Blueprintr sends a request for an integration only to an online agent that reports it, preferring the one heard from most recently, and keeps the requests of one operation on one agent. An agent older than 0.2.0 reports no list, and is used only when no agent lists the integration. A team's integrations can use the team's own agents and its parent organisation's. A sweep runs on the agent you choose, within that agent's ranges.

Is there high availability?

There is no clustering. Each agent is one process with its own identity. Two copies of one identity would take jobs from the same queue, so run each agent once: the Helm chart runs one replica for that reason, and enrolling the same agent on another host cuts off the first.

For redundancy, enrol a second agent and add the same integrations to its config.json. When one agent stops polling, requests for those integrations go to the other. These stay with one agent:

sweeps and sweep schedules, which belong to one agent. A scheduled sweep whose agent is offline is skipped;
credentials sent from Blueprintr, which go to one agent. Give a standby agent its credentials in config.json;
WhatsUp Gold and Veeam Backup & Replication tokens, which stay on the agent that obtained them. The other agent obtains its own.

What happens if our Enterprise plan lapses?

Continuum Local is judged on the plan of the organisation that owns the agent, and a team's agent uses its parent organisation's plan. Within about five minutes of a lapse:

the agent's polls are refused with a message in its log saying the plan is inactive. It keeps its configuration, keeps retrying, and resumes on its own once an owner renews;
enrolment is refused, and the enrolment token is not used up;
on-premise tabs keep their last saved snapshot and cannot be refreshed;
no sweep can start, scheduled sweeps are skipped, and past sweeps cannot be viewed until the plan is active again. The 90-day retention keeps running meanwhile, apart from each agent's latest complete sweep, which is kept until a newer one completes;
the Continuum Local panel lists the agents as paused, with Revoke, Delete and remove from agent only, so you can take them out of service.

Nothing on the agent's host is deleted: its configuration and any credentials sent from Blueprintr stay there until you remove them. A paused agent's polls are refused, so remove from agent usually reports it offline. Remove those credentials on the agent's machine instead, by deleting its state as described under Uninstall.

How long is a release supported?

Until the next one. Before version 1.0 only the latest release is supported. Fixes, including security fixes, ship in a new release, and nothing is patched in place. The download page offers the current release and a few before it, so you can install the version your change control approved or roll back. Blueprintr sends an agent only work it reports it can do, so an older agent keeps working, and a connector that needs a newer one says to upgrade. The agent never updates itself.

Other limits

Sweeps are IPv4 only. Each block in discovery.cidrs is a /22 at most unless you set a smaller maxSweepPrefix, and never larger than a /16.
Discovery uses SNMP only. There is no ICMP ping sweep or port scan.
An agent runs one sweep at a time, for 5.5 hours at most.
Sweep results appear only on the sweep pages in settings. Nothing draws them on a diagram or attaches them to a stratum.
Credentials can be sent from Blueprintr only to an agent that is online and connected to agents.blueprintr.io. Nothing is queued for an offline agent.
A linked tab changes only when an editor refreshes it. Nothing runs on a schedule apart from the sweep schedules you set.