Development · GLAZE UI V1.4 publication target

Understand the platform.
Preserve each system’s authority.

GoreeCloud Manager is the central management and operational console under development for GoreeCloud. Its current foundation prioritizes authenticated, least-privilege, read-only visibility, normalized status, bounded failure behavior, and clear ownership of every underlying system instead of creating an unrestricted superuser layer.

This is the public informational website at www.goreecloud.com/manager/; manage.goreecloud.com is retained only as a compatibility redirect. The private Manager application remains a separate application boundary. Source/build modernization of this site does not establish Manager runtime deployment, production approval, platform-system acceptance, or current GLAZE UI rendered acceptance.

Normalized visibilityConceptual · no live data
NetworkRead-only peer contextMonitoringAvailability + scheduled-job stateResourcesDelegated sanitized telemetryProtectionBackup status, not restore proofOperational workAuthorized read-only Tasks data
Implemented foundation

Read-only context from explicitly bounded integrations.

The current Manager source has implemented read-only integration foundations for NetBird, Healthchecks, Uptime Kuma, Beszel, Kopia, and GoreeCloud Tasks. Each integration remains responsible for narrow normalized fields, timeout and failure behavior, and least-privilege access.

01

Private-network visibility

NetBird-derived peer and network context is consumed through read-only authority; Manager does not become the network-control authority.

02

Health visibility

Healthchecks and Uptime Kuma provide bounded service and scheduled-job signals while remaining authoritative for their own monitoring state.

03

Delegated resource context

Beszel visibility uses a delegated host-side collector and sanitized artifact. Manager does not require the Docker socket or broad host credentials.

04

Backup context

Kopia status can inform the operational view, but backup existence is never upgraded into evidence that a restore or broader recovery will succeed.

05

Operational work

GoreeCloud Tasks exposes a dedicated read-only Manager API. Tasks retains task-data and authorization authority; Manager cannot use this integration to modify work.

06

Fail-soft orchestration

Independent integration failures are bounded so an unavailable, rejected, malformed, or timed-out adapter can degrade visibly without fabricating state or collapsing the whole overview.

Authority model

A unified view must not become a competing source of truth.

Manager normalizes selected operational information but keeps live infrastructure facts in their authoritative systems. Authentication, privacy, security, continuity, coordination, network control, monitoring, backup, and application data remain independently governed.

Visibility before mutation

The current administrative foundation is read-only. Starting, stopping, deleting, reconfiguring, or otherwise mutating infrastructure is outside the present v0.1 authority.

Least privilege

Service-specific read-only or delegated interfaces are preferred. A provider offering write APIs does not justify granting Manager write permission.

No direct Docker socket

Docker visibility must use an approved delegated least-privilege source rather than mounting the host Docker socket into Manager.

Platform systems stay distinct

GoreeCloud Identity, Privacy Shield, Wardveil Security, Everkeep, GLAZE UI, and GoreeCloud Mesh retain their own authority and acceptance boundaries.

Data minimization

Manager should receive and render only the operational fields required for approved views, while credentials, raw provider errors, and unnecessary private data remain excluded.

Direct administration survives

Manager must remain replaceable and must not become the only route to understand, administer, or recover the specialized systems it integrates.

Development and acceptance

Strong source/disposable evidence exists. Production remains separately unapproved.

Manager has accumulated source-controlled readiness evidence for authentication and sessions, runtime publication patterns, integration fault isolation, bounded execution, SQLite recovery, upgrade rollback, monitoring/alert behavior, software-supply-chain integrity, vulnerability evidence, and exact OCI build identity. These are valuable engineering gates, but they do not substitute for target-environment production evidence.

Current Development direction

  • Authenticated Django-based administrative application
  • Six implemented read-only integration foundations
  • Separate liveness and database-aware readiness semantics
  • Current GLAZE UI V1.4 publication reconciliation under review in the application repository
  • Linux and Android client work with platform-specific acceptance boundaries

Still independently gated

  • Target-environment production deployment and activation
  • Current rendered/accessibility/adaptive GLAZE UI V1.4.1 acceptance
  • Live accepted GoreeCloud Identity, Mesh, Privacy Shield, Wardveil, and Everkeep relationships where applicable
  • Production credentials, networking, monitoring, backups, recovery, update/rollback, and administrator acceptance
  • Any future state-changing or AI/MCP administrative authority

GLAZE UI V1.4 publication target. This canonical mounted publication pins the official Stable 1.4.1 release revision. Rendered, accessibility, resilience, performance, rollback, Cloudflare deployment, private Manager runtime, and production acceptance remain separate fail-closed gates.