To deploy OutSystems applications from Dev to Production, use the LifeTime console to create deployment plans with impact analysis, stage versions through QA, and manage rollbacks. This tutorial covers the full pipeline including environment-specific Site Properties, breaking change detection, database schema rollback limitations, and automating deployments with the LifeTime REST API for CI/CD integration.
LifeTime: OutSystems' Centralized Deployment Console
LifeTime is OutSystems 11's dedicated environment management console — a separate web application that gives IT teams a single pane of glass for all environments. It handles deployment planning with impact analysis, role-based access control for promotions, application version history, and environment health monitoring. In ODC, the equivalent is ODC Portal, which uses container-based deployments where the same Docker image moves between Development, Test, and Production stages without recompilation. This tutorial covers the full O11 LifeTime workflow in detail, with ODC differences noted at each relevant point. Understanding deployment pipelines is essential for any team moving beyond single-developer projects.
Prerequisites
- OutSystems 11 infrastructure with at least two environments (Development + Production; QA recommended)
- LifeTime console access — typically at https://[yourlifetimeserver]/lifetime
- IT Manager or Administrator role in LifeTime to create and execute deployment plans
- Applications already published to the Development environment via Service Studio's 1-Click Publish
Step-by-step guide
Navigate the LifeTime Console and Understand the Environment Pipeline
Navigate the LifeTime Console and Understand the Environment Pipeline
Open your LifeTime console URL (provided by your OutSystems infrastructure team — typically `https://lifetime.[yourdomain].com`). Log in with your IT Manager credentials. **Main LifeTime views:** 1. **Applications tab** (default): Lists all applications across all environments. Each row shows the application name, and columns show the deployed version in each environment (Development, QA, Production). Color indicators: green = same version, orange = newer version available, red = deployment needed or broken. 2. **Infrastructure tab**: Shows all registered environments with their status, OutSystems Platform version, and connectivity health. This is where environments are added and configured. 3. **Deployment Plans tab**: History of all past deployment plans with status (Success, Failed, Aborted) and who created them. 4. **User Management tab**: Add users, assign teams, and grant application access — access control for who can deploy to which environment. The pipeline flows left to right: **Development → QA → Production**. Each promotion requires creating a Deployment Plan.
Expected result: LifeTime Applications tab shows all your apps with version status across environments. You can see which environments have newer versions available.
Create a Deployment Plan (Dev to QA)
Create a Deployment Plan (Dev to QA)
In LifeTime → **Applications tab**, locate the application you want to promote. Click the **Deploy** button (or the version indicator in the QA column if it shows 'Deployment needed'). Alternatively: **Deployment Plans tab** → **Create Deployment Plan**. **In the deployment plan wizard:** 1. **Source environment**: Development (default) 2. **Target environment**: QA 3. **Applications to deploy**: check your application(s) 4. **Version selection**: LifeTime auto-selects the latest tagged version from Development. You can choose a specific version from the version history dropdown. 5. **Deployment notes**: add a description (e.g., 'Sprint 5 — added invoice module, bug fix for order status') Click **Continue** to proceed to impact analysis.
Expected result: A draft deployment plan is created showing the source version, target environment, and list of applications to be deployed. You see the 'Impact Analysis' button to proceed.
Run Impact Analysis and Interpret the Results
Run Impact Analysis and Interpret the Results
After defining your deployment plan, click **Run Impact Analysis**. LifeTime analyzes the changes and reports: **Impact Analysis categories:** 1. **Applications to Deploy**: Applications you explicitly selected 2. **Applications also to Deploy** (auto-added): Applications that your selected apps depend on and that also have changes — LifeTime adds these automatically to prevent broken dependencies 3. **Applications with Potential Inconsistencies**: Apps in the target environment that consume modules you are deploying — LifeTime flags these as potentially affected consumers **Breaking changes** are shown in red. These indicate API signature changes (renamed actions, removed parameters, changed output types) that will break consuming applications. Breaking changes block deployment unless: - You deploy all affected consumers in the same plan - You acknowledge and accept the breaking change **Database changes** are listed separately: new tables/columns being added (safe), columns being renamed or removed (potentially destructive), schema changes requiring data migration.
1/* LifeTime Impact Analysis — reading the results */23/* Color indicators in Impact Analysis: */4/* Green checkmark: No changes, no impact */5/* Orange warning: Changes but no breaking API changes */6/* Red X: Breaking changes — action required */78/* Common impact scenarios: */910/* SAFE to deploy: */11/* - Adding new screens, entities, actions */12/* - Adding optional parameters to existing actions */13/* - Bug fixes with no API changes */14/* - New database columns with default values */1516/* CAUTION — review before deploying: */17/* - Renamed public actions (breaks consumers) */18/* - Removed output parameters */19/* - Changed data types on existing parameters */20/* - Database column type changes */2122/* BLOCKED — must resolve before deploying: */23/* - Consumer app is not also in the deployment plan */24/* - Required dependency not available in target environment */Expected result: Impact Analysis completes and shows a summary of safe changes, potential impacts, and any breaking changes. You can expand each section to see exactly which actions, entities, or APIs are affected.
Execute the Deployment and Monitor Progress
Execute the Deployment and Monitor Progress
After reviewing the impact analysis and resolving any blocking issues, click **Deploy Now** (immediate) or **Schedule** (set a specific date/time for the deployment to run automatically). **During deployment, LifeTime shows a real-time progress indicator:** 1. Preparing deployment package 2. Uploading to target environment 3. Compiling (.OML → .NET C# + SQL scripts) 4. Deploying (updating IIS, running DB migrations) 5. Running post-deployment verifications **If deployment fails:** LifeTime shows the error at the step where it failed. Click **View Logs** to see the detailed error. Common failures: - Compilation error: unresolved TrueChange errors that exist in Development (fix in Service Studio, republish, create new plan) - Database migration failure: schema change conflicts with existing data - Permission error: LifeTime service account lacks DB permissions for schema changes After successful deployment, the QA column in the Applications tab turns green with the new version number.
Expected result: Deployment progress bar reaches 100% with a green success indicator. Applications tab shows the new version number in the QA column. The application is accessible in QA with the new features.
Deploy from QA to Production with Environment-Specific Configuration
Deploy from QA to Production with Environment-Specific Configuration
After QA testing and sign-off, create a new deployment plan from QA → Production. The same impact analysis runs for the Production environment. **Environment-specific configuration (critical step):** Values that differ between environments (API endpoints, connection strings, feature flags) are stored in **Site Properties**. LifeTime does NOT migrate Site Property values between environments — you set them per-environment in **Service Center**. Before deploying to Production: 1. Open Service Center for the Production environment (typically `https://[prod-server]/ServiceCenter`) 2. Go to Factory → Modules → [your module] → Site Properties tab 3. Set the Production values for each Site Property (API base URLs, max record limits, feature toggle flags) Back in LifeTime: create the QA → Production deployment plan → run impact analysis → deploy. Note: after deploying to Production, the version in the Production column must match QA. If Production shows a different version from QA, the deployment has not run or has not completed.
1/* Site Properties — per-environment configuration pattern */2/* Logic tab → Data tab → Site Properties → Add Site Property */34/* Example Site Properties for environment-specific config */56PaymentApiBaseUrl7 Dev value: https://sandbox.stripe.com/v18 QA value: https://sandbox.stripe.com/v19 Prod value: https://api.stripe.com/v11011MaxRecordsPerPage12 Dev value: 5013 QA value: 5014 Prod value: 1001516EnableNewFeature17 Dev value: True /* Feature flag — on in Dev for testing */18 QA value: True19 Prod value: False /* Not yet ready for production */2021/* Accessing Site Properties in logic */22Site.PaymentApiBaseUrl23Site.MaxRecordsPerPage24If(Site.EnableNewFeature, NewFeatureWidget, OldFeatureWidget)Expected result: Production deployment completes successfully. All three environment columns (Dev, QA, Prod) show the same version number. Production-specific Site Properties are set correctly in Service Center.
Roll Back a Production Deployment
Roll Back a Production Deployment
If a production deployment causes issues, LifeTime supports deploying any previous version. **Rollback procedure:** 1. In LifeTime → Applications tab → click the affected application 2. Click **View application details** → **Versions** tab — shows full version history 3. Find the version you want to restore (previous good version) 4. Click **Deploy this version** → LifeTime creates a deployment plan to put this older version back in Production 5. Run impact analysis → deploy **Critical limitation: database schema rollbacks** LifeTime can redeploy older application code, but it CANNOT reverse database schema migrations. If your new version added columns or tables, those remain in the database after rollback. If it deleted or renamed columns, the data is gone. **Best practice for schema-risky deployments:** - Add new columns with default values (never removes data) - Use a 'rename' as two-step: add new column → migrate data → keep old column as deprecated → remove in next sprint - Test database migration scripts in QA before Production **Deployment error — cannot rollback:** If a deployment fails midway, LifeTime may leave the environment in a partially deployed state. Contact OutSystems support or manually re-run the deployment with the previous version.
Expected result: The rollback deployment plan completes and the Production column shows the previous version number. The application behaves as it did before the problematic deployment. Any database schema additions from the rolled-back version remain (harmlessly) in the database.
Integrate LifeTime with CI/CD Pipelines (LifeTime API)
Integrate LifeTime with CI/CD Pipelines (LifeTime API)
LifeTime exposes a **REST API** that lets you automate the entire deployment pipeline from external tools like Jenkins, Azure DevOps, or GitHub Actions. **Authentication:** LifeTime API uses service account tokens. In LifeTime → User Management → create a service account user → assign it Deploy Application role → generate API token. **Key API endpoints (base URL: `https://[lifetime-host]/lifetimeapi/rest/v2`):** - `GET /environments` — list all environments with keys - `GET /applications/{app_key}/versions` — get version list - `POST /deployments` — create deployment plan - `POST /deployments/{plan_key}/start` — execute deployment - `GET /deployments/{plan_key}` — check deployment status **Typical CI/CD flow:** 1. Developer pushes to feature branch → merge to main 2. CI pipeline triggers LifeTime API: create deployment plan Dev → QA 3. Wait for status = Finished_Successful 4. Run automated tests in QA 5. If tests pass: create deployment plan QA → Production → execute 6. Monitor status → notify team on success/failure OutSystems provides open-source reference CI/CD pipelines on GitHub (search 'outsystems-pipeline' on github.com).
1/* LifeTime API — GitHub Actions workflow snippet */2/* (illustrative — use outsystems/setup-outsystems-action for full impl) */34# .github/workflows/deploy.yml (excerpt)56# Step 1: Get environment keys7# GET /lifetimeapi/rest/v2/environments8# Header: Authorization: Bearer {SERVICE_ACCOUNT_TOKEN}910# Step 2: Get application version from Dev11# GET /lifetimeapi/rest/v2/applications/{APP_KEY}/versions1213# Step 3: Create deployment plan Dev → QA14# POST /lifetimeapi/rest/v2/deployments15# Body:16# {17# "ApplicationVersionKeys": ["version-key-here"],18# "Notes": "Automated CI/CD deployment — Build #123",19# "SourceEnvironmentKey": "dev-env-key",20# "TargetEnvironmentKey": "qa-env-key"21# }2223# Step 4: Execute deployment24# POST /lifetimeapi/rest/v2/deployments/{plan_key}/start2526# Step 5: Poll status27# GET /lifetimeapi/rest/v2/deployments/{plan_key}28# DeploymentStatus values: saved, running, needs_user_intervention,29# aborted, finished_successful, finished_with_warnings3031/* ODC DevOps APIs — similar pattern using ODC Portal APIs */32/* https://success.outsystems.com/documentation/outsystems_developer_cloud/devops_apis/ */33/* Supports: Asset Repository, Builds, Deployments, Impact Analysis */Expected result: CI/CD pipeline successfully calls LifeTime API to create and execute deployment plans automatically on code merge. Team receives Slack/Teams notification on deployment success or failure. Manual LifeTime access is only needed for exceptional cases.
Complete working example
1/* ============================================================2 OutSystems LifeTime — Deployment Checklist & Key References3 ============================================================ */456/* === PRE-DEPLOYMENT CHECKLIST (run before every Production deploy) === */78/* 1. TrueChange in Service Studio shows zero RED errors (warnings OK) */9/* 2. All features tested in QA environment */10/* 3. Site Properties verified in Production Service Center */11/* 4. Database migration impact reviewed (additive-only changes are safest) */12/* 5. Rollback version number documented */13/* 6. Deployment scheduled for low-traffic window */14/* 7. Post-deploy smoke test steps prepared */151617/* === ENVIRONMENT URLS (typical pattern) === */18/* Development: https://dev.[yourdomain].com */19/* QA: https://qa.[yourdomain].com */20/* Production: https://[yourdomain].com */21/* LifeTime: https://lifetime.[yourdomain].com */22/* Service Center Dev: https://dev.[yourdomain].com/ServiceCenter */232425/* === SITE PROPERTIES ACCESS === */26/* Service Center → Factory → Modules → [Module] → Site Properties */27/* Or: Service Studio → Data tab → Site Properties → set Default Value */28/* Per-environment override: Service Center only (not Service Studio) */293031/* === VERSION HISTORY === */32/* LifeTime: Applications → [App] → View Details → Versions tab */33/* Service Center: Factory → Modules → [Module] → Versions tab */343536/* === DEPLOYMENT STATUS VALUES (LifeTime API) === */37/* saved — plan created, not started */38/* running — deployment in progress */39/* needs_user_intervention — blocked, manual action required */40/* aborted — deployment was cancelled */41/* finished_successful — deployment completed with no errors */42/* finished_with_warnings — completed but with non-blocking warnings */434445/* === ODC DEPLOYMENT DIFFERENCES === */46/* No LifeTime console — use ODC Portal */47/* Environments: Development → Test → Production (3 stages) */48/* Deployment = promoting a container image (no recompilation) */49/* DevOps APIs: same concept as LifeTime API, different endpoints */50/* Rollback: redeploy previous container image (same limitations on DB) */51/* Secret Settings: encrypted, per-stage values (replaces Site Properties) */52/* ODC Portal: portal.outsystems.com → your organization → Deployments */535455/* === LIFETIME API BASE URL === */56/* https://[lifetime-host]/lifetimeapi/rest/v2 */57/* Auth: Bearer token from service account */58/* Key endpoints: */59/* GET /environments */60/* GET /applications/{key}/versions */61/* POST /deployments */62/* POST /deployments/{key}/start */63/* GET /deployments/{key} */Common mistakes
Why it's a problem: Creating a deployment plan that does not include all affected consumer applications when deploying a module with breaking API changes, causing production consumers to break immediately after deployment.
How to avoid: Always review the 'Applications with Potential Inconsistencies' section in Impact Analysis. If consumers are shown as affected by breaking changes, either include them in the same deployment plan or resolve the breaking change in the producing module before promoting.
Why it's a problem: Forgetting to set Production-specific Site Property values in Service Center before deployment, causing the app to use Development API keys or sandbox endpoints in Production.
How to avoid: Create a pre-deployment checklist that explicitly includes 'verify all Site Properties in Production Service Center' as a required step before marking a deployment as approved.
Why it's a problem: Attempting to roll back a deployment that renamed or deleted database columns, expecting data to be restored — the rollback only reverts the code, not the schema.
How to avoid: Treat all database deletions and renames as irreversible production operations. Plan schema migrations as multi-step: (1) add new column, (2) migrate data, (3) remove old column in a future deployment after verifying no code references the old column.
Why it's a problem: Using a personal LifeTime user account for CI/CD pipeline authentication instead of a dedicated service account, causing pipeline failures when the user changes their password or the account is deactivated.
How to avoid: Create a dedicated LifeTime service account (User Management → Add User) with the minimum required permissions (Deploy Application role on specific apps) and use its API token for all CI/CD automation.
Best practices
- Never publish directly to Production from Service Studio — always use LifeTime to ensure impact analysis runs, deployment notes are recorded, and the change is traceable.
- Enforce a branching strategy where only specific team leads have 'Deploy to Production' permission in LifeTime — this adds a human gate before production deployments.
- Keep database schema changes additive (add columns, add tables) wherever possible — never rename or delete columns without a multi-sprint migration plan, because rollbacks cannot reverse schema changes.
- Configure LifeTime email notifications for deployment events — team leads should receive alerts for deployment start, success, and failure so no deployment goes unnoticed.
- Run the LifeTime API-based CI/CD pipeline for all QA deployments, but require a manual approval gate in the pipeline before the QA → Production step.
- Verify Site Properties in each target environment's Service Center immediately after deployment — these are the most common source of production bugs after a clean LifeTime deployment.
- Use AI Mentor Studio's Architecture analysis to reduce module coupling before deploying large changes — fewer module dependencies mean smaller deployment plans and less impact analysis risk.
- In ODC, container-based deployments mean the same compiled artifact moves from Development to Test to Production — if it ran in Test, it will run identically in Production, eliminating compilation-time surprises.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm managing OutSystems 11 deployments and need to understand the LifeTime console. Explain: (1) the Dev → QA → Production pipeline flow in LifeTime, (2) how to create a deployment plan and what impact analysis shows for breaking changes vs safe changes, (3) how to set environment-specific configuration using Site Properties in Service Center vs Service Studio, (4) how to roll back a production deployment and what the database schema rollback limitations are, and (5) the key LifeTime REST API endpoints for automating deployments in a CI/CD pipeline. Note where ODC differs with its container-based deployment model.
I need to deploy my OutSystems application from Development to Production using LifeTime. Walk me through: creating a deployment plan in LifeTime Applications tab, interpreting impact analysis results (what red vs orange indicators mean), handling the case where my module has breaking changes that affect consumer apps, setting the Production values for my Site Properties in Service Center before deploying, executing the deployment and monitoring the progress steps, and verifying the deployment was successful. Also explain how to roll back if something goes wrong.
Frequently asked questions
Can I deploy individual modules or only entire applications in LifeTime?
LifeTime deploys at the application level — you select applications, and LifeTime automatically includes all modules within those applications plus any dependent modules that have changes. You cannot deploy a single module in isolation if it belongs to an application with other modules that need to stay in sync. This is by design to ensure consistency.
What is the difference between LifeTime deployment and 1-Click Publish in Service Studio?
1-Click Publish in Service Studio deploys directly to the environment you are currently connected to — typically Development. It has no impact analysis, no deployment notes, and no approval workflow. LifeTime is the proper deployment pipeline for promoting between environments (Dev → QA → Production). For production, always use LifeTime — direct Service Studio publishing to Production is an anti-pattern that bypasses all governance controls.
How long does a LifeTime deployment take?
Deployment time depends on the number of modules and the complexity of changes. A typical deployment of a single application with 3-5 modules takes 5-15 minutes including upload, compilation, and deploy steps. Large enterprise applications with 20+ modules can take 30-60 minutes. Compilation is the longest step — subsequent deployments of unchanged modules are faster because LifeTime caches compiled packages.
How does ODC deployment differ from LifeTime in OutSystems 11?
ODC uses container-based deployments where your app is compiled once in Development into a Docker container image, then that same image is promoted to Test and Production without recompilation. This makes ODC promotions much faster (typically 2-5 minutes) and eliminates 'works in QA but fails in Production' compilation issues. Configuration differences between stages are handled via Secret Settings and Settings (equivalent to Site Properties) configured in ODC Portal per stage.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation