Skip to content

Cloud Overview

XWidget Cloud is a deployment and analytics platform for XWidget apps. It lets you push UI updates — fragments and value resources — to your users without going through app store review cycles.

How It Works

You deploy bundles of XML fragments and value resources to XWidget Cloud, then publish them to channels. Your app's XWidget runtime downloads the bundle its channel currently serves and renders the UI from it. When you publish an update, users get the new UI on their next app launch.

You work with XWidget Cloud through two complementary clients backed by the same platform: the xc CLI and the web Console. Deploying is CLI-only — the CLI bundles the resources in your project directory — while everything after that (publishing, channels, analytics, workspace management) is available from both. Use whichever fits the moment: the CLI for scripting and release pipelines, the Console for visibility and one-click operations.

Core Concepts

XWidget Cloud organizes everything under a workspace and project hierarchy. Within a project there are two independent things: deployments (the immutable bundles you upload) and channels (pointers that decide which bundle each app population receives).

Workspaces

A workspace is the top-level container and usage boundary. It groups related projects and controls who has access. Each workspace has members with assigned roles, and usage metrics are tracked at the workspace level.

When you first authenticate with XWidget Cloud, a default workspace is created for you.

Projects

A project maps to a single Flutter app. It holds the deployments and channels for that app. When you run xc cloud deploy for the first time in a project directory, the CLI creates a cloud project automatically and writes the project ID to xwidget_cloud.yaml in your project root:

project_id: 5Tv_2OaW_2v8DPrlIKxzg

This file links your local project directory to its cloud counterpart. Subsequent CLI commands use this ID to resolve the project without prompting.

Each project has a project key and a storage key used for client authentication and content access. You can retrieve these with xc cloud project keys and rotate the project key with xc cloud project rotate-key if it's compromised.

Deployments and Revisions

A deployment is an immutable snapshot of your app's UI resources — the XML fragments and value files bundled into a tarball. Each deployment is identified by a version (e.g. 1.0.0, 1.2.0+42) plus a revision — a number the platform assigns automatically, counting from 0, every time you deploy that version. Deploying 1.0.0 three times produces revisions 0, 1, and 2; nothing is ever overwritten, so every revision remains available for publishing or rollback.

Deploying does not change what your users see. A fresh deployment is staged: it exists in the cloud but no channel serves it until you publish it.

Channels

Channels are named release tracks within a project — typically production, staging, and dev, but you can name them whatever you want. A channel is a set of pointers, one per version it serves: publishing points the channel's pointer for that version at a chosen revision. The same revision can be live on any number of channels at once, and moving a pointer is instant — no bytes are copied.

This makes promotion and rollback the same operation: publish the revision you want the channel to serve. Roll back by publishing an earlier revision; promote a tested revision from staging to production by publishing it there too.

Channel names must be 30 characters or less and can only contain letters, numbers, hyphens, and underscores. The name local is reserved.

Warning

Renaming a channel that client apps reference will stop those apps from receiving updates until they're updated with the new name.

Typical Workflow

  1. Authenticate: xc cloud login
  2. Deploy: xc cloud deploy -v 1.0.0 — uploads the bundle and mints a revision (say rev 0). The CLI offers to publish it right away.
  3. Publish to staging: xc cloud publish -c staging -v 1.0.0 -r 0
  4. Test the update in your staging app build.
  5. Publish the same revision to production: xc cloud publish -c production -v 1.0.0 -r 0
  6. Monitor with xc analytics renders and xc analytics downloads.

Because publishing just moves a pointer, step 5 makes production serve the exact bytes you tested on staging.

Every step after the deploy works from the Console too — publish and roll back from the Deployments page, monitor from the Analytics pages.