Why App Management in Splunk Cloud Requires a New Approach
Managing apps in Splunk Enterprise on Premise is relatively straightforward. You can upload, configure, and update apps directly through the UI or file system. However, in Splunk Cloud, this process is much more restrictive. By default, administrators cannot manage apps directly like they have done prior
This difference presents a major challenge for organizations migrating to the cloud. Especially those that rely on frequent updates or manual changes.
Fortunately, Splunk provides a solution: the Admin Config Service (ACS). This API unlocks capabilities that bring Splunk Cloud closer to the flexibility of an on-premises environment.
The Gap Between Enterprise and Cloud
On Splunk Enterprise, app management is direct. You install apps via the UI or copy them to the file system. This allows for quick testing, adjustments, and deployments.
However, Splunk Cloud prioritizes stability and security. As a result, direct access to file systems or unmanaged app uploads is not permitted. UI-based configuration changes are stored separately and not included in app packages.
These overrides can disrupt deployment consistency. This makes it essential to centralize and standardize app configurations.
ACS as the Gateway to Cloud App Management
The Admin Config Service (ACS) API is the key to app management in Splunk Cloud. With ACS, you can list, install, delete, and update apps. You can also control app visibility and trigger restarts when needed.
This brings flexibility back into your workflow. More importantly, it allows teams to standardize app configurations, even without a CI/CD pipeline.
When paired with a structured workflow, ACS enables app deployment with reduced friction and improved governance.
Prerequisites for Using ACS
To use the Admin Config Service (ACS), certain conditions must be met:
- Splunk Cloud Experience: ACS is available on both Classic and Victoria experiences. However, specific ACS features (such as app export) may only be supported on Victoria. Always consult the ACS compatibility matrix when using advanced features.
- Role-Based Access: The user’s role must contain the capabilities required to access the desired ACS endpoints. The sc_admin role includes all necessary capabilities by default.
- Token Authentication: ACS requires authentication using a bearer token generated by a valid admin user.
If your organization uses SSO, ensure you have a corresponding local admin account to generate the token.
These access controls ensure that ACS can be used securely while supporting scalable management practices in Splunk Cloud.
A Manual Workflow for Managing Custom Apps
The following process allows administrators to manage apps manually using ACS. It ensures updates do not conflict with prior UI-driven changes.
1. Export the Existing App from Splunk Cloud
Before making updates, download the current version of the app. Use ACS or request the package from Splunk Support. This includes both default/ and local/ directories.
To export a specific app using ACS (only available on Splunk Cloud deployments using the Victoria Experience):
curl -X GET "https://admin.splunk.com/{stack}/adminconfig/v2/victoria/export/download/{app_name}" \
-H "Authorization: Bearer $TOKEN" \
-o {app_name}.tar.gz
Replace {app_name} with the app’s name and {stack} with your stack name. This downloads the installed app package in .tar.gz format, which includes both default/ and any saved configurations.
2. Merge Any Local Changes into default/
Run AppInspect with the —included-tags cloud flag. This confirms the app meets Splunk Cloud standards.
splunk-appinspect inspect myapp.tar.gz --mode precert --included-tags cloud
Fix any errors. Eliminate warnings if possible.
3. Validate the App Using AppInspect
Check the contents of the local/ folder. Migrate any permanent or important changes into the app’s default/ directory.
Once merged, repackage the app:
tar -czvf myapp.tar.gz myapp/
This prevents those changes from being lost or causing conflicts during deployment.
4. Remove the App from Splunk Cloud
To ensure a clean update, delete the app from Splunk Cloud before uploading a new version.
curl -X DELETE "https://admin.splunk.com/{stack}/adminconfig/v2/apps/{app_name}" \
-H "Authorization: Bearer $TOKEN"
This clears the local/ directory and prevents conflicts.
5. Upload the Clean Package via ACS
Deploy your validated app package using the ACS API.
curl -X POST "https://admin.splunk.com/{stack}/adminconfig/v2/apps" \
-H "Authorization: Bearer $TOKEN" \
-F "app_package=@myapp.tar.gz" \
-F "visible=true" \
-F "restart=true"
6. Verify Deployment and App Behavior
Use ACS to confirm that the app was deployed successfully. Test its functionality within Splunk Cloud. Review logs and dashboards to ensure everything works as intended.
Note: All ACS endpoints provided in this section refer to the Classic Experience unless otherwise stated. For Victoria Experience deployments, /victoria must be added after /apps in the endpoint path where applicable (such as for install, delete, or list operations).
Recommended: Enforce Policy and Prevent UI Drift
Allowing users to make changes through the Splunk Cloud UI introduces configuration drift. These changes are stored in the local/ directory, which is preserved across app updates. As a result, they can override the default/ configurations in your deployed package.
By enforcing a policy that locks down UI changes, teams can eliminate this risk. Restricting configuration changes to only ACS-enabled admins ensures that all updates follow a standardized and controlled process.
This makes app updates much easier to manage. It also ensures consistency and reduces support overhead caused by mismatched configurations.
Optional: Transition to a CI/CD Pipeline
While the manual approach works, teams with automation capabilities can benefit from CI/CD. This approach adds version control, continuous validation, and standardized deployments.
There are a few important Splunk-specific considerations:
- The app version in the packaged .tar.gz must be incremented. Splunk Cloud will not install an identical version if one already exists.
- Automation must account for the preservation of local changes. These must be merged into default/ before packaging.
- Because of this, your automation must still include logic to:
- Download the current version of the app
- Merge any local changes
- Delete the existing app using ACS
- Reinstall the newly packaged version
By integrating AppInspect and ACS into a pipeline, teams reduce human error. They also gain better visibility into changes and rollback capabilities.
Conclusion
Splunk Cloud doesn’t support app management the way Splunk Enterprise on Premise does. However, with ACS and a structured process, manual or automated, teams can restore this flexibility.
By validating apps with AppInspect, managing updates through ACS, and optionally implementing CI/CD, administrators gain reliability. They also gain predictability and compliance.
This workflow prevents configuration drift. It also improves your ability to scale and secure your Splunk Cloud environment.
To access more Splunk searches, check out Atlas Search Library, which is part of the Atlas Platform. Specifically, Atlas Search Library offers a curated list of optimized searches. These searches empower Splunk users without requiring SPL knowledge. Furthermore, you can create, customize, and maintain your own search library. By doing so, you ensure your users get the most from using Splunk.
