Service Studio already ships with a powerful but underdocumented headless execution mode. Through hands-on reverse engineering, we have confirmed and validated the following commands: -d (diff), -refresh, -u, -uu, -exportSettings, -importSettings, -cleanup, -removeChangeTracking, -runTests, -export, -import, and -silentrecover.
These existing commands prove that Service Studio is architecturally capable of running fully headless, without opening a GUI. This proposal builds on that foundation to request ten new CLI commands that would unlock:
- AI-powered codebase analysis on .oml files without a running GUI
- CI/CD pipeline integration via GitHub Actions, Docker, and Linux environments
- Automated dependency management, publishing, and solution creation
- Programmatic introspection of modules, applications, elements, and SS_Keys
These requests do not change the OutSystems platform concept or runtime. They expose what the IDE already does — through a command-line interface that can be scripted, automated, and run in containers.
Proposed New Commands
1. ss list-apps — List Applications with Names and SS_Keys
Problem: There is no headless way to enumerate the applications available on a server, along with their SS_Key (the GUID used by servicestudio:// deep links and LifeTime APIs).
2. ss list-modules — List Modules with Names and SS_Keys
Problem: Modules are the atomic unit of development in OutSystems, but there is no headless way to enumerate them with their SS_Key GUIDs — the identifiers required for servicestudio:// protocol links and element navigation.
3. ss check-deps — Verify Module Dependencies Before Publish
Problem: Before publishing a module, a developer needs to know if its dependencies are up to date, or if a producer module was published with breaking changes. The current workflow requires opening Service Studio, navigating to "Manage Dependencies," and manually inspecting each reference. There is no headless equivalent.
4. ss publish — Publish a Module
Problem: There is no headless command to publish a module to a server. The current workflow requires opening Service Studio and clicking "1-Click Publish." This blocks full CI/CD automation.
5. ss republish — Republish a Module (Service Center Style)
Problem: Service Center provides a "1-Click Publish" that recompiles and redeploys a module using its last published OML source, without requiring the source file on disk. This is critical for environment redeployments, disaster recovery, and CI/CD rollbacks — but it has no CLI equivalent.
6. ss list-elements — List All Elements of a Module by Name and SS_Key
Problem: To use the servicestudio:// deep link protocol (e.g., to link directly to a specific action from a CI report or an AI analysis tool), you need the SS_Key of the element. Currently, the only way to get element keys is through direct database access or by reverse engineering internal API calls.
7. ss add-action — Add a Simple Action Using a Mermaid-Style Flow Definition
Problem: Creating a simple server or client action in Service Studio requires opening the GUI, navigating to the correct module, and manually building the flow. For repetitive, pattern-based actions (logging, error handling, standard API calls), this is a barrier to AI-assisted code generation.
8. ss for Linux — Docker and GitHub Actions Support
Problem: Service Studio is currently only available for macOS and Windows. This means CI/CD pipelines running on Linux (the default for GitHub Actions, GitLab CI, and most Docker containers) cannot use any Service Studio CLI commands. This is the single biggest blocker for full OutSystems DevOps automation.
Request: Provide a headless Linux build of Service Studio — or a dedicated CLI package — that supports the full set of headless commands (existing + proposed) on:
- Ubuntu 22.04 / 24.04 (standard GitHub Actions runners)
- Alpine Linux (Docker optimization)
- Debian-based containers
9. ss delete-unused-refs — Delete Unused References from a Module
Problem: Over time, modules accumulate references to producers that are no longer used — dead imports that slow down compilation, add maintenance overhead, and generate noise in -refresh / -u verification output. Service Studio can detect these via "Manage Dependencies," but there is no headless way to auto-clean them.
10. ss create-solution — Create Solutions Programmatically
Problem: Solutions in OutSystems are the primary vehicle for managing and deploying groups of modules across environments via LifeTime. Creating and maintaining solutions is currently only possible through the Service Center UI. For teams managing complex multi-module deployments, the lack of a CLI solution creator is a significant DevOps gap.
Why This Matters: The AI Analysis Use Case
The combination of -listModules, -listElements, and the existing -d (diff) enables a use case that is currently impossible: AI-powered static analysis of OutSystems codebases without a running GUI.
Current Gap: To analyze an OutSystems application with AI today, a developer must:
- Manually open each module in Service Studio
- Navigate through hundreds of screens, actions, and flows
- Copy/paste relevant information into an AI tool
The AI agent can then generate a report like:
"Action IsElegivelAntecipacaoDZero (key: 11ea244a-...) accesses the server on every screen load. Consider moving this to an Aggregate with proper caching. → [Open in Service Studio](servicestudio://-downloadAndOpen -eSpaceKey 6acebf97-... -elementKey 11ea244a-... -url bin.dev.myenvironment.com)"
This is only possible if -listElements exposes SS_Keys in its output.
Summary
We are requesting 10 new headless CLI commands for Service Studio, with Linux support as the foundational requirement for CI/CD automation. The existing headless CLI (-d, -refresh, -u, -exportSettings, etc.) proves the architecture is ready. These new commands extend that foundation to cover the full development lifecycle — from introspection and dependency management, to publishing, solution creation, and AI-powered analysis.
The OutSystems platform is already exceptionally powerful. These commands make that power accessible to modern DevOps and AI tooling workflows, without changing a single line of platform behavior.