CloudControl

Edge-first network operations

Your network engineer is already at the edge.

Observe Ethernet, Wi-Fi, and cellular paths. Prove the connection you intend to use. Run guarded diagnostics and recovery through an assigned edge—even after the browser disappears.

Account and DDNS hostname now. Hardware coordinated separately.

ETHERNETroute readyWI-FIprovenCELLstandbyEDGE ROUTERASSIGNEDEDGECLOUDCONTROL

The gap below the dashboard

“Offline” is not a diagnosis.

Route drift

The link is up. The traffic is leaving through the wrong source or gateway.

Carrier NAT

The address changed, but ordinary monitoring cannot tell whether inbound access is possible.

Wi-Fi loss

The remembered network still exists; the router simply stopped using it.

Blocked overlays

IKE, NAT-T, DNS, or a required port fails before the tunnel has a chance.

Smart Hands at the edge

See the path. Prove it. Change only what matters.

CloudControl turns a supported edge router into a careful pair of remote hands—not a blind command pipe.

01
01

Observe

Interfaces, source addresses, gateways, route evidence, and edge-observed public IP.

02
02

Prove

Run a specific test from the place where the connection is supposed to work.

03
03

Act

Apply capability-gated operations with explicit confirmation and an audit trail.

04
04

Recover

Restore known-good connectivity and move through viable underlay candidates.

Multi-connectivity

One site. Every usable path.

CloudControl can observe and recover across configured Ethernet, Wi-Fi, USB, and cellular underlays, then prove the overlay you depend on.

Path-aware recovery · not WAN bonding
Ethernet

Route ready

Wi-Fi

Proven

Cellular

Standby

USB uplink

Available

Optional connection layer

WireGuardIPsec / StrongSwanOpenVPNCustom proof

Recovery ladder

Recover the route before dispatching a person.

The exact path remains profile- and capability-aware. CloudControl works from known-good evidence rather than promising a universal sequence.

  1. 01

    Restore edge-proven configuration

  2. 02

    Re-establish DHCP and route fallthrough

  3. 03

    Promote a viable Ethernet, USB, or cellular path

  4. 04

    Rejoin a remembered Wi-Fi network

  5. 05

    Refresh networking and radios

  6. 06

    Use a supervised restart when warranted

Field diagnostics

Evidence from where the failure lives.

01

HTTPS throughput

Measure what the active path can actually deliver from the remote site.

02

MTR + traceroute

See where loss and latency enter the route instead of guessing from an offline dot.

03

TCP · UDP · DNS

Test the exact port, protocol, resolver, and direction an overlay depends on.

04

Public + overlay iperf3

Separate underlay performance from WireGuard or IPsec tunnel performance.

05

IKE / NAT-T viability

Check whether the network can carry an IPsec negotiation before changing configuration.

06

Bidirectional proof

Use nonce-based evidence to show that the intended connection works both ways.

Guarded operations

Powerful where supported. Explicit where risky.

Inspect interfaces, storage, power, thermals, cellular modems, USB devices, clients, and policies. Capability-gated controls make the hardware boundary visible before you act.

Remote operation

Restart network service

Confirmation required
✓Capability checked
✓Action audited
✓Result verified
bound device → assigned edge
no dependency on the browser session

Automation with a reason

Trigger on evidence. Cool down. Verify the result.

When

WAN changed

Prove the overlay after an accepted public-IP change.

When

Reachability lost

Collect diagnostics after repeated failure, not a single dropped packet.

When

Recovery planned

Notify operators before and after supervised work.

When

Maintenance window

Stage a signed agent upgrade with rollback available.

Trust architecture

Control flows toward the edge.

Bound devices communicate with their assigned edge—not the public sales site. Commands have durable custody, duplicate-safe IDs, capability checks, and auditable results.

1

Operator UI or automation

Request with authenticated intent

2

CloudControl control service

Admission · audit · durable custody

3

Assigned edge

MQTT QoS 1 + HTTPS fallback

4

Bound device

Unique credentials · capability-gated execution

Lucent Drift DDNS

Claim the name before the router arrives.

Your account can reserve a managed name.lucentdrift.online immediately. When hardware reports a usable public address, CloudControl updates and independently verifies DNS.

Stable naming is not NAT traversal. CGNAT still requires the assigned edge or a proven overlay path.

Hostname lifecycle

01

Claimed

Held for your account; no fake address while hardware is in transit.

02

Observed

The assigned edge accepts the active path’s public address evidence.

03

Synchronized

A deduplicated update reaches Lucent Drift without another device command.

04

Verified

CloudControl resolves the name independently and reports convergence.

Start today

An account now. A real operating plan today.

Create your account, reserve your hostname, and describe the first sites without waiting for a call. Completed profiles target same-business-day control-plane preparation; hardware is coordinated separately.

Create your CloudControl account ↗
  1. Now

    Account + owner workspace

    Sign in, name the organization, and claim DDNS.

  2. Today

    Review + isolated control plane

    We review the completed profile and prepare the dedicated runtime.

  3. Next

    Hardware coordination

    Sales confirms a compatible supported device and shipping.

  4. On arrival

    Enroll + baseline

    Bind the device to its assigned edge, prove paths, and establish the baseline.

Guided pilot

A production-shaped start, without invented pricing.

Every pilot is scoped to the sites, connectivity, hardware, and recovery outcome that matter. You can build the account and technical profile before a commercial conversation.

  • ✓Dedicated control-plane plan
  • ✓Assigned-edge placement review
  • ✓Managed hostname claim
  • ✓Supported-device onboarding
  • ✓Connectivity and proof baseline
  • ✓Recovery and operator handoff

Questions worth asking

Plain answers.

Does CloudControl bond links?

No. It observes and recovers across configured path candidates; it does not market Ethernet, Wi-Fi, and cellular as a bonded zero-loss connection.

What happens behind CGNAT?

The stable DDNS name still updates, but inbound reachability needs the assigned edge or a proven WireGuard, IPsec, OpenVPN, or custom path.

Does it work with any router?

The pilot targets supported OpenWrt and GL.iNet profiles. Hardware-dependent functions appear only when the device advertises them.

Can I create an account before speaking to sales?

Yes. Account, owner workspace, technical profile, and initial managed hostname are available immediately.

What happens when the browser closes?

The control service, assigned edge, and bound device continue their work. The browser is not in the device communication path.

Ready when the site is not

Put smart hands at your edge.

Create the account. Claim the hostname. Build the pilot profile today.

Create account ↗