Questions about the planned Service Planet platform

A planned DevOps and IT infrastructure team in one platform, with its own specialized AI assistant for internal IT teams and MSPs. Chat, topology, cost and status would connect discovery and assessment to proposed changes, exact approval, qualified execution, verification and monitoring. A read-only first implementation is recommended, not the entire product identity. People remain accountable; software-enforced permissions, validated tools, policy gates, sandbox evaluation and audit are essential. Adapting an existing model or suitable open-source/open-weight components remains under evaluation, not a commitment to train a foundation model from scratch or a guarantee of safety.

Yes. Internal IT teams would review their own authorized environments; MSPs would review customer environments with access kept separate. Both may have multiple deployments across mixed cloud and dedicated infrastructure. Internal IT overview.

No production availability is announced. The app and open-source software are in planning, not a released service or download. This website describes the intended direction; it does not implement the app, integrations, agents or operations. Release scope and any evaluation must be confirmed before access is offered.

AWS, Azure and Google Cloud are targets across services, not only compute, with Azure the initial qualification recommendation. Microsoft 365 and Google Workspace need separate tenant, service and licensing or cost qualification. No provider name implies complete coverage, support for every operation or launch availability.

Service Planet’s own workspace is the primary planned interface, with web, iOS and Android management clients separate from the deployable backend/control plane and OS agents. Shared authentication, tenant permissions, approvals and audit must apply across those clients. MCP would support optional, individually qualified external AI clients. No mobile app, implementation framework, app-store availability or offline behavior is established.

OS-installed agents would support qualified Windows and Linux hosts, with read-only collection recommended first. Agents are separate from the control plane and cannot by themselves cover every network device or physical asset. Private-cloud provisioning and cross-environment migration are planned execution areas requiring separate qualification, exact approvals, compatibility and dependency checks, data consistency, cutover, cost, downtime and action-specific recovery evidence.

Yes, as planned capabilities delivered after qualification and the recommended read-only starting point. Patch work begins with discovery, advisories, lifecycle and applicability review; execution needs approved plans, maintenance windows, staged rollout, visible reboot/availability impact and post-update validation. Optional self-healing would have an on/off control for selected database, server OS or networking resources. A default-off design is recommended, with separately human-approved policies, bounded runbooks and recovery prerequisites; high-risk changes remain separately gated. Monitoring is not repair permission. Neither execution nor self-healing is available or enabled by this website, and inventory cannot provide universal rollback.

Current topology should distinguish observed connections from inferred relationships. A proposed future topology is a scenario, not a deployed result. Actual charges, forecasts and scenario estimates remain separate, with sources, periods, currencies, cost bases and assumptions. Estimated savings are not guaranteed.

Configurable monitoring is planned. Recommendations and any future alerts would use Security, Performance and Health & Availability groups. Status must distinguish up, degraded, down and unknown, with freshness and coverage visible; reachability or stale data cannot prove health. Supported signals, thresholds, cadence and retention need definition. Notifications and configurable alert settings are tentative secondary options, with no channels or behavior selected. Technical research would identify authoritative sources, relevant versions and freshness, expose uncertainty and assess compatibility, security and lifecycle. Research must not trigger automatic upgrades.

The confirmed direction is open-source software you can self-host, optional managed hosting and separately purchasable support, à la carte. No download, specific license, prices, support terms, SLA or availability is selected. Linux-based packaging and a custom distribution remain evaluation options. Self-hosting is not a promise of offline use or zero operating cost; application licensing, model-weight licenses and training-data rights are separate decisions.

Start with an authorized infrastructure question and a clear measure of success. The environment, supported coverage, deployment model and data handling must be agreed before connecting anything. The service availability page shows a workflow request form only when inquiries are enabled. Never submit credentials or customer records.