Design: Overview

Cloudpack aims to reduce the friction in building, testing, and shipping changes to applications and their dependencies.

The current focus is increasing inner loop speed and decreasing friction of cross-repo local development. (We also have many future ambitions for making the development, dependency management, and deployment experiences even easier!)

This page outlines the major benefits and fundamental concepts of Cloudpack. For deeper technical details, see the linked pages.

Key benefits

Faster startup times

For large enterprise apps with thousands of source files, library mode makes cloudpack start at least 2-5x faster than webpack-dev-server. This applies to:

• Cold start - First run with no cached bundles
• Warm start - Cache populated from previous run and/or sync
• Watch mode - Incremental rebuilds during development

Performance can be further improved by enabling remote cache sync to download pre-bundled packages from a shared cache.

Cross-repo development

cloudpack link makes it much easier to test library changes against a consuming app in another repo.

Before Cloudpack:

1. Clone the app repo
2. Clone the library repo
3. Run npm link and hope it works
4. Debug duplicate React copies in the dependency graph
5. Manually rebuild on every change

With Cloudpack:

1. Run cloudpack start in the app repo
2. Run cloudpack link in the library repo
3. Changes automatically sync to the running app

Core concepts

At a high level, Cloudpack:

1. Resolves dependencies into a graph of packages and their entry points
2. Generates an import map that tells the browser where to find each package
3. Bundles packages on demand when the browser requests them
4. Caches aggressively at multiple levels (browser, disk, remote) to avoid re-bundling

The browser loads your app using native ES modules with the import map handling resolution. When you edit code, Cloudpack detects the change, re-bundles only the affected package, and refreshes the browser.

For a mid-level overview of the bundling process, see the Bundling page. For a deep dive, see Architecture.

Operation modes

Cloudpack supports two bundling modes:

Library mode

Library mode (the default) bundles each package as an isolated ES module. Key characteristics:

• Each package entry point becomes a separate bundle
• Unchanged packages are served from cache
• Fast incremental updates (only re-bundle the edited package)
• Ideal for development

When app code imports a package in the browser during cloudpack start, the import map routes requests to the bundle server. The server either bundles the package, returns a cached result, or redirects to a remote cache if configured.

See Bundling: Library mode for details.

Production mode

While library mode is great for inner loop development, downloading thousands of bundles is not optimal for end-user application performance. Production mode creates optimized bundles for deployment, including tree shaking, minification, and code splitting.

See Bundling: Production mode for details.

Bundler abstraction

Cloudpack is designed to be bundler-agnostic, and internally it chooses between multiple bundlers depending on which one is best for the job. Currently we support the following, but we can easily add more bundlers when the next new thing arrives!

Bundler	Primary use case
Ori	Default for TS and ESM (fastest)
Rollup	CommonJS packages
Webpack	Production builds, AMD
Rspack	When HMR is enabled

WARNING

By design, Cloudpack does not read existing bundler configs like webpack.config.js. See Bundling: Bundler abstraction for the full explanation.

ES modules and import maps

Cloudpack outputs ES modules and uses import maps for browser resolution. This avoids transforming import statements at dev time, contributing to fast startup.

See ES Modules for background on module formats and how Cloudpack uses them.

Caching strategy

Cloudpack caches at multiple levels:

1. Browser cache - Long-lived caching via content hashes in URLs
2. Local disk cache - Bundled output stored by package hash
3. Remote cache (optional) - Shared bundles via Azure Blob Storage

Each package gets a deterministic hash based on its contents, dependencies, and configuration. When anything changes, the hash changes, and a new bundle is created.

See Architecture: Caching strategy for details.

Next steps

• CLI - Commands and their behavior
• Bundling - Bundler selection, ESM stubs, and import maps
• ES modules - Module format background and Cloudpack's approach
• Architecture - How the servers, caching, and real-time updates work