Remote Access Platform
Production-oriented Secure Access Fabric platform.
The project started as an RDP proxy, but the target architecture is broader:
- multi-tenant control plane
- direct realtime data plane
- service adapters for RDP now and VNC/SSH/VPN/file/video later
- native Access Clients
- future secure mesh / node-agent / updater / connector model
- shared Fabric Service Channel runtime for working service data so VPN, Remote Workspace, video, file, and future services request a common channel instead of reimplementing transport, routing, and failover
RDP is the first proven service baseline. RDP work is currently paused by product decision while the project moves to the Secure Access Fabric platform-core foundation: clusters, node enrollment, node-agent identity, role assignments, and platform administration.
Current Baseline
- Backend: Go control plane with PostgreSQL as source of truth and Redis for live coordination/routing only.
- Worker: active C++ RDP Adapter worker based on FreeRDP.
- Windows client: C# / WPF native Access Client.
- Data plane: direct worker WSS for realtime RDP when available, backend WebSocket gateway retained as fallback/debug.
- Current test Docker host:
docker-test/192.168.200.61. - Current test Docker deployment for Stage 5.2 proof:
rap-backend-smoke:stage5-2-downloadandrap-rdp-worker:stage5-2-download.
See the current audit and baseline matrix before starting new work:
docs/audits/PROJECT_AUDIT_2026-04-26.mddocs/audits/CURRENT_BASELINE_MATRIX.md
Proven RDP Capabilities
- real RDP connect through worker
- active/detach/reattach/takeover/terminate lifecycle
- takeover without remote session recreation
- worker-death/orphan-active-session recovery
- direct worker WSS data plane
- binary direct render frames
- backend gateway JSON/base64 fallback
- Windows client rendering and input
- text clipboard with policy enforcement
- client-to-server file upload into controlled worker storage
- restricted transfer-drive visibility through
RAP_Transfers, runtime-proven - server-to-client file download implementation through
RAP_Transfers\ToClient; core direct/fallback data path is runtime-proven, lifecycle blocking is runtime-proven, and manual desktop UI acceptance remains pending
Repository Structure
backend/- Go control planeworkers/rdp-worker/- active C++ RDP Adapter workerworkers/rdp-service-csharp/- inactive research scaffold, not current runtimeclients/windows/- Windows native Access Clientclients/android/- Android VPN clientdocs/architecture/- target and staged architecture documentsdocs/codex/- current Codex status and next-step promptsdocs/audits/- current audits and baseline matricesscripts/- smoke and helper scriptsdeploy/- deployment assetsweb-admin/- future/admin UI area
Быстрый локальный билд Android APK после апдейта
pwsh -ExecutionPolicy Bypass -File scripts\prepare-local-build-workstation.ps1 -SetEnvironment
pwsh -ExecutionPolicy Bypass -File scripts\android\prepare-android-build-environment.ps1 -SetEnvironment
pwsh -ExecutionPolicy Bypass -File scripts\android\rebuild-and-publish-android-apk.ps1
Для быстрого release (сборка + публикация + опциональная проверка манифеста):
pwsh -ExecutionPolicy Bypass -File scripts\android\release-android-apk.ps1 `
-InstallMissing `
-PublishToTestDockerDownloads
Для одного шага «всё-в-одном»:
pwsh -ExecutionPolicy Bypass -File scripts\android\fast-release-android-apk.ps1
Или через .cmd (Windows, двойной клик/ссылкой):
scripts\android\fast-release-android-apk.cmd
После обновления Android-клиента выполните на машине сборки:
pwsh -ExecutionPolicy Bypass -File scripts\android\rebuild-and-publish-android-apk.ps1 -InstallMissing -BuildType release
Скрипт сам проверит окружение, при необходимости поставит недостающие компоненты
SDK (флаг -InstallMissing) и соберет APK. После этого артефакт сразу окажется в
web-admin/deploy/html/downloads для скачивания из панели.
Важно по процессу релиза: каждый новый номер версии должен проходить полный цикл
сборка → публикация → проверка manifest и всегда попадать в latest-release +
releases/<version> на стороне дистрибутива, чтобы узлы и пользователи всегда
обновлялись с актуального билда.
Read Order
CODEX_CONTEXT.mddocs/audits/PROJECT_AUDIT_2026-04-26.mddocs/audits/CURRENT_BASELINE_MATRIX.mddocs/codex/CURRENT_STATUS.mddocs/codex/ARCHITECTURE_GUARDRAILS.mddocs/architecture/RDP_ADAPTER_RUNTIME.mddocs/architecture/DATA_PLANE_V1.mddocs/architecture/FABRIC_SERVICE_CHANNEL_RUNTIME.mddocs/architecture/CLUSTER_NODE_ADMIN_FOUNDATION.mddocs/codex/NEXT_STEP_PROMPT.md
Do not use docs/_legacy_v1 for implementation decisions. Legacy files are
historical reference only.
Current Next Step
RDP work is paused. Platform-core stages C1-C9 are implemented and verified:
cluster/node model foundation, node enrollment hardening, native
rap-node-agent MVP, Platform Admin Console MVP, service workload supervision
contract, mesh control-plane preparation, Mesh MVP skeleton, multi-cluster
hardening, and organization admin foundation.
Planning baseline:
docs/architecture/CLUSTER_NODE_ADMIN_FOUNDATION.mdartifacts/c1-cluster-node-foundation-report.mdartifacts/c2-node-enrollment-hardening-report.mdartifacts/c3-rap-node-agent-mvp-report.mdartifacts/c4-platform-admin-console-report.mdartifacts/c5-service-workload-supervision-contract-report.mdartifacts/c6-mesh-control-plane-preparation-report.mdartifacts/c7-mesh-mvp-skeleton-report.mdartifacts/c8-multi-cluster-hardening-report.mdartifacts/c9-organization-admin-foundation-report.md
Stage C1 implemented the backend foundation for:
- explicit clusters
- cluster memberships
- node join tokens with hashed tokens only
- node join requests
- node identity/certificate metadata
- node role assignments
- node heartbeat/latest health
- cluster audit events
- safe migration/backfill of existing node data into a default cluster
Recommended next step is a decision between platform auth hardening for web-admin, node PKI hardening, node-agent runtime hardening, mesh runtime DP-0, or returning to paused RDP work.
Do not start all continuation paths at once.