One platform. Your boundary.

Hosted, dedicated private, or independently self-hosted.

NoBS Remote is intended to meet organizations where their operational boundary lives. All three modes are product direction today—not available production services.

Planned deployment choices

Deploy / 01

NoBS-hosted

NoBS is intended to operate the control plane and supporting service so a customer can focus on using the product.

NoBS-operated updates, monitoring, backups, and incident response.
Tenant authority inside the hosted service.
Capacity and regions published only after measurement.

Planned

Deploy / 02

Dedicated private

A NoBS-operated environment with a dedicated operational boundary matched to the customer engagement.

Isolation and responsibility defined in writing.
Operations remain with NoBS unless the engagement says otherwise.
No availability, residency, or isolation level is promised before validation.

Conditional engagement

Deploy / 03

Independent self-hosted

A customer-operated control plane intended to authorize sessions without a mandatory NoBS session service.

Linux Docker is the primary server target.
PostgreSQL is the initial production database target.
Install, update, backup, restore, and diagnostics must pass customer-run testing.

Planned

Current reality: the repository contains development Docker Compose and PostgreSQL plumbing. It is not a supported hosted or self-hosted product, and it does not enable screen viewing or remote control.

Responsibility before marketing

Every deployment must say who owns what.

Final service descriptions will define these boundaries before a customer is asked to rely on them.

Responsibility	NoBS-hosted	Dedicated private	Independent self-hosted
Business and session authority	NoBS-operated tenant environment	Defined by the dedicated engagement	Customer-operated control plane
Server operations	NoBS	NoBS unless expressly assigned otherwise	Customer, using supported tooling
Backups and recovery	NoBS, against published objectives	Documented engagement responsibility	Customer, with tested product procedures
Endpoint private/content keys	Never intended for the service	Never intended for the service	Never intended for the control plane
Availability today	Not available	Not available	Not available

Same authority rules

Private does not mean a weaker product.

The goal is consistent consent, revocation, endpoint identity, audit, and version rules across modes. A deployment label must never bypass the endpoint trust boundary.

Different operating realities

Operations remain explicit.

Recovery objectives, updates, relay ownership, monitoring, capacity, support, and incident duties vary by mode. They will be published and tested instead of hidden behind the word “private.”

Planning a private boundary?

Tell us what your organization actually needs.

Founding Pilot conversations can inform the dedicated and self-hosted operating models.

Apply to the pilot View architecture direction