Config Bundles in CI/CD
A config bundle is a versioned JSON snapshot that contains everything the SDK needs to run without a network connection: onboarding flows, paywalls, in-app messages, feature flags, experiment definitions, and remote config values. By embedding a config bundle in your app binary during CI/CD, you guarantee a fully configured experience on first launch — even if the user has no internet connection.What is a Config Bundle?
The config bundle is a single JSON file generated server-side whenever you publish changes in the dashboard. It contains:
Each bundle includes a
bundle_version number that increments on every generation, along with metadata like generated_at and sdk_min_version.
API Endpoints
Download Current Bundle
x-api-key header.
Returns the full config bundle including all content. This is the endpoint you call in your CI/CD pipeline.
Check Bundle Version
x-api-key header.
Lightweight version check that returns metadata without the full content payload. Useful for polling or conditional downloads in CI.
This endpoint returns only metadata (no
content field), making it ideal for checking whether you need to download a new bundle before every build.Force Regenerate Bundle
Authorization: Bearer header, plus x-tenant-id / x-app-id.
Forces the server to regenerate the config bundle from the current published state of all modules. Returns the newly generated bundle.
The platform automatically regenerates the bundle whenever you publish changes in the dashboard. Manual regeneration is rarely needed but can be useful in CI/CD pipelines that need to ensure the bundle reflects the very latest state.
Bundle Version History
Authorization: Bearer header, plus x-tenant-id / x-app-id.
Returns a paginated list of previous bundle versions with metadata. Useful for auditing or rollback workflows.
CI/CD Integration
Adding a config bundle download step to your build pipeline takes three steps:1
Add a build step that downloads the bundle
Call
GET /api/v1/sdk/config-bundle with your SDK API key and save the response to a JSON file.2
Save the file to the platform-specific assets directory
Each platform expects the file in a specific location (see platform-specific examples below).
3
Build your app as normal
The SDK automatically detects the bundled config file and uses it as the last-resort fallback when no remote or cached config is available.
Build Script Examples
- Fastlane (iOS)
- Gradle (Android)
- Flutter
- React Native
Add a lane or a pre-build action to your Make sure
Fastfile:Resources/appdna-config.json is added to your Xcode project under Build Phases > Copy Bundle Resources.Version Checking
The SDK automatically compares the local bundled version with the remote version on startup:- On launch, the SDK reads
bundle_versionfrom the embedded config file. - It calls
GET /api/v1/sdk/config-bundle/versionto check the latest server version. - If the server version is newer, the SDK downloads the full bundle and caches it locally.
- The bundled version is only used if both the remote fetch and cache miss fail.
Best Practices
- Regenerate on every deploy. Even if you have not changed any configuration, regenerating ensures the bundle version stays current and the staleness warning stays green.
-
Use the
x-api-keyheader, not Bearer tokens. The config bundle download endpoint accepts SDK API keys, which are scoped to your app and safe to use in CI environments. -
Fail the build if the download fails. Use
curl -sf(silent + fail on error) or equivalent so your build breaks visibly if the download fails, rather than shipping an outdated or missing bundle. -
Store the API key as a CI secret. Never hardcode
APPDNA_SDK_KEYin your build scripts. Use your CI provider’s secret management (GitHub Actions secrets, Bitrise secrets, etc.). - Check the file size. A valid config bundle is always at least a few hundred bytes. If the downloaded file is 0 bytes or suspiciously small, the download likely failed silently.

