Support development

The current path is donation support, not subscription

xpod Cloud currently stays a hosted preview with a free baseline. If you want to support development, the current path is a domestic payment-code flow, and supporter status is claimed manually instead of becoming a higher quota tier.

Current positioning

The current focus is to keep the hosted preview and self-hosted path stable, not to promise a formal subscription. Donations are there to support development, infrastructure, and operations rather than to buy a larger resource tier.

How support works

The current support path is designed for domestic users through payment codes. If collection later moves to a company account or a formal provider, the supporter record can stay compatible without changing the free baseline.

  • Domestic payment-code entry
  • Mainly for domestic users
  • Can later move to a company collection channel

If you want to claim supporter status

After payment, prepare the claim details for manual review. Once approved, billing records a manual entitlement that marks supporter status without automatically raising free quotas.

  • xpod accountId
  • Email or GitHub username
  • Payment channel and amount
  • Payment time and screenshot

What supporter means

A supporter record expresses a support relationship, not a subscription tier. Right now it is suitable for supporter badges, priority communication, and best-effort early access.

Keeps

What stays

Supporter badge, priority communication, and early-access style non-resource benefits.

Boundary

What does not happen automatically

A donation does not auto-enable larger storage, bandwidth, or model quotas.

Resources

What remains true

The account still inherits the platform free baseline, and resource policy stays under xpod control.

Next step

Understand the boundary first

If deployment and runtime control are your main questions, go to xpod docs first. If you want to support the work, use the manual claim flow.