Workspaces
Keep customers separated
Role-scoped workspaces, devices, sites, support queues, notes, policies, and history must resist cross-customer mistakes.
I run an IT business
Remote support is operating infrastructure, not a nice-to-have.
NoBS Remote is being designed for small IT teams and MSPs that must move quickly without losing customer separation, technician accountability, policy, or a sustainable commercial model.
Product experience plannedThe intended fit
Operational control sized for the business.
These are design requirements, not available features.
Technicians
Make authority match the job
Least-privilege technician roles, explicit requests, visible consent, and reliable Stop should be part of the normal workflow.
Operations
Diagnose without exposing secrets
Useful status, bounded failure codes, audit, export, retention, deployment, and recovery should support the operator without leaking customer content.
Intended workflow
From queue to accountable resolution.
- Receive or create a customer-bound support request.
- Assign an authorized technician inside the correct workspace.
- Verify device, requester, local consent, and current session state.
- Support through bounded, policy-aware capabilities.
- Capture useful notes and audit, then end authority and clean up.
Foundation only
No production MSP console exists.
The current Web Admin is a scaffolded developer foundation, explicitly not final product UI. Production identity, RBAC, support queue, policies, real Viewer, transport, content capabilities, licensing, billing, and operational tooling remain planned.
Deployment fit
Match the service boundary to customer obligations.
NoBS-hosted
The intended managed path for teams that want NoBS to own platform operations, backups, updates, and service response.
PlannedDedicated private
A future NoBS-operated boundary for an MSP or customer engagement with separately defined isolation and operating duties.
ConditionalIndependent self-hosted
A future customer-operated Linux Docker/PostgreSQL control plane without mandatory NoBS session authorization.
PlannedSecurity and governance
Cross-customer mistakes must fail closed.
Production roles, workspaces, device selection, policies, support queues, audit, exports, and retention require explicit tenant context and negative testing before MSP claims ship.
Pricing direction
Support growth without a licensing ambush.
Plans should separate understandable technician, fleet, usage, relay, support, and private-deployment economics. Exact units and prices will be published before paid access.
Read pricing principlesFounding Pilot fit
Show us how a real small IT operation survives.
Bring customer boundaries, queue pressure, technician roles, after-hours support, deployment, reporting, and commercial constraints.
Are multi-customer workspaces available?
No. They are required product direction, but production identity, roles, queue, policy, and cross-tenant evidence are not complete.
Will there be usage or relay limits?
Bounded rate, concurrency, session-duration, relay-byte, and fair-use behavior are planned. Exact units and limits will be published with measured capacity and pricing.
Will the MSP be able to self-host?
Independent self-hosting is a first-class target, but the customer must own operations and pass supported install, update, backup, restore, diagnostics, and failure-recovery workflows.