Add Pickforge Pro Managed Cloud Labs

[ElbertePlinio]

Goal

Add Pickforge Pro Managed Cloud Labs: users run PickLab Linux and Windows tests without creating or administering their own cloud account. Pickforge provisions isolated disposable machines in a dedicated GCP environment, shows and reserves the maximum charge before launch, streams evidence, and deletes the infrastructure.

This is the managed follow-up to BYOC Cloud Labs in #39. Issue #39 remains the open-source/community path and must not absorb this service’s billing, untrusted-code, legal, or abuse boundary.

Product model

Tier	Infrastructure	Experience	Billing
Community	User’s GCP project	Cost calculator + automated BYOC lifecycle	User pays Google
Pickforge Pro	Pickforge-managed isolated runners	Select target, approve maximum, run, receive evidence	Included/prepaid lab credits
Teams	Pickforge-managed runner pool	Organization budgets, approvals, concurrency, shared evidence	Team subscription + usage

Managed V1

• Linux and Windows Server compatibility targets.
• Build-artifact upload only; no source-repository ingestion or user-supplied VM images.
• One isolated disposable VM per run.
• One concurrent run and strict runtime/machine/disk/upload limits for new accounts.
• No GPU, nested virtualization, inbound hosting, or exact Windows 11.
• Private evidence with short retention and user-controlled deletion.

Not Managed V1

• Unlimited usage.
• Exact Windows 11 BYOL/sole tenancy.
• Shared customer desktops or arbitrary RDP/SSH access.
• General-purpose compute, hosting, crawling, scraping, mining, or security-testing service.
• Persistent arbitrary file storage.

Monetization and credit safety

Reuse Pickforge’s existing Supabase Auth, Stripe Checkout helpers, and credit ledger. Extend the ledger atomically with reservation semantics:

reserve maximum charge → consume actual runtime → release unused reservation

• Publish a Pickforge rate card rather than promising exact GCP pass-through pricing.
• Show rate/minute, maximum runtime, maximum charge, reserved credits, and expected release before approval.
• Refuse provisioning without enough available credits.
• Stop before the approved reservation can be exceeded.
• Keep create, reserve, settle, release, refund, and retry operations idempotent.
• Distinguish platform failure, user-artifact failure, test failure, evidence failure, and policy termination in refund rules.
• Fence new runs and stop/settle active runs before account deletion completes.
• Add strict new-account, daily, monthly, organization, and concurrency caps.
• Threat-model stolen cards, chargebacks after cloud consumption, account farming, and promo-credit abuse.
• Reassess Stripe Metronome only when usage volume, enterprise contracts, or rating complexity outgrow the existing prepaid ledger.

Critical trust boundary

No GCP credentials does not prevent prohibited uploads or behavior. The managed service intentionally gives users an upload path and executes their artifacts in Pickforge’s account. An artifact can also generate or download prohibited material after a clean upload.

Pickforge is responsible for controlling end-user use of its GCP environment and responding to abuse reports/notices.

Primary policy sources:

• Google Cloud Acceptable Use Policy: https://cloud.google.com/terms/aup
• Google Cloud Terms: https://cloud.google.com/terms
• Google Cloud abuse response: https://docs.cloud.google.com/docs/security/respond-to-abuse-misuse
• Google Cloud malware-scanning architecture: https://docs.cloud.google.com/architecture/automate-malware-scanning-for-documents-uploaded-to-cloud-storage

Prohibited-content and acceptable-use release gate

Before any public managed beta:

• Publish an Acceptable Use Policy prohibiting illegal material, copyright infringement, malware/ransomware, phishing, credential theft, spam, cryptocurrency mining, denial-of-service activity, unauthorized security testing, exploitation, prohibited sexual content, child exploitation material, export-control violations, and attempts to bypass controls.
• Require the user to attest that they own or are authorized to test each artifact and that it does not intentionally contain or retrieve prohibited material.
• Publish abuse, legal, copyright/takedown, appeal, repeat-infringer, suspension, and law-enforcement response procedures reviewed by qualified counsel.
• Provide public reporting channels using the existing legal@pickforge.dev and security@pickforge.dev aliases until a dedicated form is justified.
• Define jurisdiction, retention, notice, preservation, deletion, and account-termination rules. Do not improvise DMCA/LGPD/legal obligations in application code.
• Define what happens to reserved/consumed credits when a run is rejected or terminated for policy reasons.
• Train administrative review so quarantined material is never casually downloaded to a personal workstation.

Automated scanning cannot establish copyright ownership, licensing rights, authorization to test software, legality of datasets, or future runtime behavior. Policy, notices, runtime isolation, and human/legal response remain necessary.

Upload state machine

requested
→ uploading
→ quarantined
→ scanning
→ approved
→ delivered once to runner
→ expired/deleted

Failure path:

quarantined/scanning
→ rejected
→ account signal recorded
→ object deleted according to policy

Only an immutable object generation in approved state can be delivered to a runner.

Upload controls

• Authenticate every upload and bind it to one user, organization, run ID, object path, maximum size, expected platform/type, checksum, and short expiry.
• Upload into a private quarantine bucket that runners and ordinary users cannot read.
• Validate actual file signatures/magic bytes; extensions and MIME headers are not trusted.
• Managed V1 allowlist: .exe, .msi, .AppImage, .deb, .rpm, and .apk only where the target supports them.
• Reject encrypted/password-protected archives, arbitrary disk/VM images, unknown multipart formats, excessive archive depth, archive bombs, and expanded-size violations.
• Scan the exact immutable object generation for known malware before approval; prevent replacement between scan and execution.
• Record checksum, actual type, size, scan time, scanner/signature version, decision, and event ID.
• Keep quarantine, approved, evidence, and administrative-review storage separated with least-privilege identities.
• Treat uploads, URLs, GitHub releases, and any future artifact ingress identically; alternative download paths cannot bypass quarantine.
• Define false-positive handling and appeal. One heuristic or scanner finding must not automatically become a permanent account ban without severity/context policy.
• Treat scanning as one defense only; scanners have false negatives and cannot prove legal ownership.

Reference architecture:

short-lived upload
→ private unscanned bucket
→ Eventarc
→ private Cloud Run scanner
→ approved bucket OR quarantine/rejection
→ one-time runner delivery

Managed-runner isolation

Each run is hostile/untrusted by default.

• Dedicated ephemeral VM per run; never execute multiple customers on one guest.
• Guest has no attached GCP service account and no cloud credentials available through metadata.
• Controller remains outside the guest and performs all privileged cloud operations.
• No public ingress, public RDP/SSH, production route, Supabase/Stripe/Sentry secret, or runner-to-runner connectivity.
• Brokered one-time artifact download and narrowly scoped evidence upload; no bucket credentials in the guest.
• Isolated VPC/subnet boundary with deny-by-default lateral access.
• Restrict egress; block metadata/private ranges, SMTP, peer-to-peer/abuse-sensitive traffic, and unapproved inbound hosting.
• Decide the minimum internet required for realistic app testing and expose it through an explicit policy/proxy rather than unrestricted default egress.
• Set infrastructure-level maxRunDuration and STOP/DELETE action independent of client/controller health.
• Bound CPU, memory, disk, network, upload, evidence, and runtime. No GPU or nested virtualization initially.
• Stream evidence during execution so cleanup does not depend on a final bulk upload.
• Delete guest, disk, ephemeral networking, artifact, and temporary credentials after the retention contract permits.

Google notes that VM processes can ordinarily access credentials exposed by an attached service account; managed runners should therefore have no attached service account by default:
https://docs.cloud.google.com/iam/docs/best-practices-service-accounts

Runtime abuse detection

Detect and respond to:

• Sustained anomalous CPU or resource patterns consistent with mining.
• Unexpected large downloads/uploads or network-volume spikes.
• Port scanning, SMTP, peer-to-peer, Tor/proxy abuse, and attempts to reach private/metadata ranges.
• Repeated malware detections, encrypted/malformed uploads, scanner bypass attempts, or forbidden file types.
• Many accounts sharing device/payment/network signals.
• Rapid run creation, concurrency-limit evasion, and repeated forced terminations.
• Attempts to host public services, attack third parties, or access neighboring workloads.

Do not send artifact contents, sensitive filenames, full customer paths, or private infrastructure identifiers to ordinary telemetry.

Abuse-response state machine

signal detected
→ stop active run when severity requires
→ block new runs
→ freeze unsettled reservations
→ preserve minimum authorized audit metadata
→ delete/quarantine content according to policy
→ review
→ restore, restrict, suspend, or terminate
→ notify/report where legally required

• Separate artifact status, run status, billing status, and account-enforcement status.
• Make enforcement and cleanup idempotent and auditable.
• Preserve only legally/policy-required evidence; do not retain prohibited material indefinitely “just in case.”
• Provide an appeal path for false positives and dual-use developer tools.
• Add a break-glass global kill switch for managed provisioning.
• Respond to GCP abuse notices within a documented owner/on-call workflow.

Privacy and artifact handling

• Private storage only, encryption at rest, and short default retention (final duration requires legal/product approval).
• User-visible disclosure of scanning provider, processing region, retention, human-access conditions, stored hashes/metadata, and deletion behavior.
• Signed short-lived evidence access; users and organizations see only rows/objects authorized through RLS and ownership.
• Immediate user deletion where legal/incident holds do not apply.
• No source repositories in V1; artifact-only upload reduces but does not remove IP/privacy risk.
• Scanner/admin access is least-privilege and audited.
• False-positive review happens in an isolated administrative environment, not on employee personal machines.

Windows boundary

• Managed V1 uses Google-provided Windows Server Desktop Experience images and agent/broker access.
• No shared user desktop and no RDS farm. More than two simultaneous RDP sessions can trigger separate RDS CAL requirements.
• Exact Windows 11 remains outside managed V1 because of VDA and sole-tenant licensing/cost.
• Complete a licensing review before public Windows managed labs.

Reference: https://docs.cloud.google.com/compute/docs/instances/windows/ms-licensing-faq

Architecture direction

PickLab client
→ authenticated Pickforge Pro API
→ atomic credit reservation
→ durable run queue
→ GCP controller
→ isolated no-identity runner VM
→ streamed private evidence
→ cloud-enforced expiry/delete
→ settle actual Pickforge rate and release unused reservation

• Supabase: Auth, Pro entitlement, organizations, RLS, credit reservations/ledger, run status, artifact metadata, audit metadata.
• Edge Function/API: authenticate, authorize, validate plan, reserve credits, enqueue; do not own a multi-hour runner lifecycle.
• Durable controller: provision, health, transport, meter, stop/delete, orphan recovery.
• GCP: isolated runners, private storage/scanning pipeline, networking controls, infrastructure TTL, audit logs.

Supabase background functions remain bounded by wall-clock/CPU/memory limits; long-lived runner ownership requires a durable external controller/worker:
https://supabase.com/docs/guides/functions/background-tasks

Technical and product spikes

• Threat model untrusted binaries, tenant isolation, controller compromise, artifact ingress, egress abuse, and administrative review.
• Unit economics using real Add cost-aware GCP Cloud Labs #39 dogfood runs: provisioning time, runtime, disk/network/scanner cost, failed-run cost, support reserve, and price-drift margin.
• Prove atomic credit reserve/consume/release plus account-deletion and chargeback races.
• Prove quarantine → scan → immutable approval → one-time delivery with duplicate Eventarc events and scanner failures.
• Prove no runner can access a cloud identity, private service, neighboring runner, quarantine bucket, or another user’s evidence.
• Prove controller/client death still deletes infrastructure and settles or safely recovers billing.
• Run legal review for AUP, privacy, copyright/takedown, retention, Windows licensing, tax/refund, export control, and abuse response.

PR / delivery plan

• Phase 0 — Threat model, legal policy, and unit economics
  • No public managed provisioning.
  • Produces approved trust boundaries, rate-card assumptions, AUP/privacy drafts, abuse owner, and go/no-go criteria.
• PR 1 — Credit reservation and managed-run records
  • Supabase/@pickforge/billing: reserve, consume, release, idempotency, RLS, deletion fencing, tests.
• PR 2 — Quarantine and immutable artifact approval
  • Signed ingress, file validation, malware scanning, buckets, duplicate-event handling, retention/deletion, private evidence metadata.
• PR 3 — Isolated Linux managed runner
  • Durable controller, no-service-account guest, network restrictions, TTL, evidence stream, metering, orphan cleanup.
• PR 4 — Abuse controls and capped private beta
  • Limits, detection, kill switch, reporting/review workflow, refunds, support runbook, monitored beta.
• PR 5 — Windows Server managed target
  • Only after Linux security/reliability and licensing gates pass.
• Public beta only after security review, forced-failure exercises, legal review, and current-head review are complete.

Cross-repo PRs link this parent issue with Refs. Only the final PR satisfying the complete managed-V1 contract uses Closes.

Feature flag

Flag: managedCloudLabs from @pickforge/flags, default off.

• Merged behind managedCloudLabs
• Internal dogfood with flag on
• Small capped private beta
• Enabled in the intended Pro release
• Flag removed after the enabled release proves stable
• Remove the flagged label when the flag is removed

Done when

• Users can run an approved Linux managed test without any GCP credentials and cannot exceed the displayed maximum charge.
• Uploads cannot bypass quarantine, validation, scanning, immutable approval, or retention/deletion policy.
• A compromised runner cannot obtain cloud credentials, reach production/private networks, contact neighboring runners, or persist after expiry.
• Controller/client/network failure still deletes the environment and settles billing safely.
• Prohibited-content policy, reporting, review, appeal, takedown, privacy, refund, and GCP-abuse workflows are published, owned, and exercised.
• Windows is added only after Linux proves the managed trust boundary and licensing review passes.