Spryker Documentation

Getting started with cloud administration

Thu, 16 Jul 2026 15:05:07 +0000

This document is a starting point for managing your Spryker Cloud Commerce OS (SCCOS) cloud environments. SCCOS is a fully managed solution. Before you start developing, we set up environments, tools, and services based on your Onboarding Questionnaire. If you didn't request something in the questionnaire, you can always do it via [support](https://support.spryker.com). After the initial setup, the following is configured and available: - [Environments](/docs/ca/dev/environments-overview.html): staging and production. - Services: RDS database, RDS backup, logs, SMTP, etc. - Access to AWS, internal resources, and services. - CD pipelines for staging and production environments. - Domain names and SSL certificates. ## Accessing the cloud environments You can access your cloud environments via the following means: - IAM account: provides access to the AWS Management Console and AWS CLI. For instructions, see [Connecting to AWS Console and CLI with an IAM user](/docs/ca/dev/access/connecting-to-aws-console-and-cli-with-an-iam-user.html). - SSH: provides access to internal services via [bastion host](https://docs.aws.amazon.com/managedservices/latest/userguide/using-bastions.html). For instructions, see [Connect to services via SSH](/docs/ca/dev/access/connect-to-services-via-ssh.html). - VPN: provides access to internal services via [bastion host](https://docs.aws.amazon.com/managedservices/latest/userguide/using-bastions.html). You receive these access details during the onboarding. - SFTP: provides access to the SFTP folder mounted inside the Jenkins container. You receive these access details during the onboarding. ## Service credentials You can find the credentials for services in the environment variables for the Zed container in [Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html). For instructions, see [Locate service credentials](/docs/ca/dev/access/locate-service-credentials.html). ## CD pipelines The following CD pipelines are configured in [CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html):

| Pipeline | Details | | --- | --- | | DESTRUCTIVE | You can configure the installation stage of this pipeline in `config/install/destructive.yml`. | | NORMAL | You can configure the installation stage of this pipeline in `config/install/production.yml`. | | Build | Compiles images and pushes them into the [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html). Starts automatically when a new commit's detected. | | Rollout Scheduler | Deploys the scheduler. |

To learn about running pipelines, see [Deploy in a staging environment](/docs/ca/dev/deploy-in-a-staging-environment.html) and [Deploy in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). ## Next step [Environments overview](/docs/ca/dev/environments-overview.html)

Connecting to AWS Console and CLI with an IAM user

Thu, 16 Jul 2026 15:05:07 +0000

This document describes how to access the AWS Management Console and configure AWS CLI access as an IAM user with Multi-Factor Authentication (MFA) enforced.

Prerequisites

AWS CLI installed on your machine.
An IAM user account and credentials provided by your administrator. If you need an account, contact support.

In your browser, open the sign-in URL provided by your administrator.

Sign-in URL

The sign-in URL contains the ID of the account you are signing into. The pattern is https://{AWS_ACCOUNT_ID}.signin.aws.amazon.com/console/. Alternatively, you can sign in at the general sign-in endpoint by entering the account ID manually.

The sign-in page opens with the Account ID (12 digits) or account alias field entered automatically.

Enter your IAM user name and Password.
Select Sign in.
When prompted, enter the MFA code from your authenticator application.

You are now signed in to the AWS Management Console.

Step 2: Generate access keys

Access keys are the long-term static credentials used to configure AWS CLI. Generate them once and store them securely.

Access key scope

You can only generate an access key for your own account.
Access keys are intended for local development and personal AWS CLI access only. Do not use them for automations.

In the AWS Management Console navigation bar, click your username > My Security Credentials.
On the Security credentials page, click Create access key.
On the Access key best practices & alternatives page, select Command Line Interface (CLI), then click Next. The Create access key window opens. Your access key has been generated.
Click Download .csv file to save the credentials.
Optional: To view the secret key in this window, click Show secret access key.

Store the downloaded credentials securely. The secret access key is shown only once.

Step 3: Configure static credentials in your terminal

Because MFA is enforced, you need temporary session credentials to use the AWS CLI. Static credentials alone are only used to request those temporary credentials.

Start by clearing any previously exported credentials to ensure no stale values are used:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

Then export your static access key pair:

export AWS_ACCESS_KEY_ID="{YOUR_ACCESS_KEY_ID}"
export AWS_SECRET_ACCESS_KEY="{YOUR_SECRET_ACCESS_KEY}"

Replace {YOUR_ACCESS_KEY_ID} and {YOUR_SECRET_ACCESS_KEY} with the values from the .csv file you downloaded in Step 2.

Step 4: Find your MFA device ARN

To retrieve your MFA device serial number, use the AWS CLI:

aws iam list-mfa-devices

The output contains a SerialNumber field with a value in the following format:

arn:aws:iam::{ACCOUNT_ID}:mfa/{DEVICE_NAME}

Note this value — you need it in the next step.

Step 5: Generate temporary session credentials

Use one of the following options, replacing the placeholders with your values:

Option A: Step by step

Request temporary credentials from AWS STS and save the output to a variable:

temp_creds=$(aws sts get-session-token \
  --serial-number {MFA_DEVICE_ARN} \
  --token-code {MFA_TOKEN_CODE} \
  --query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" \
  --output text)

Read the three values from the output into separate variables:

read -r AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN <<< "$temp_creds"

Export them to your terminal session:

export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

Clean up the temporary variable:

unset temp_creds

Option B: Single command

Run all of the above as a single command:

temp_creds=$(aws sts get-session-token \
  --serial-number {MFA_DEVICE_ARN} \
  --token-code {MFA_TOKEN_CODE} \
  --query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" \
  --output text) \
&& read -r AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN <<< "$temp_creds" \
&& export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN \
&& unset temp_creds

Placeholder	Description
`{MFA_DEVICE_ARN}`	The `SerialNumber` from Step 4.
`{MFA_TOKEN_CODE}`	The current 6-digit code from your authenticator application.

Example:

temp_creds=$(aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/john.doe \
  --token-code 521288 \
  --query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]" \
  --output text) \
&& read -r AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN <<< "$temp_creds" \
&& export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN \
&& unset temp_creds

The command fetches temporary credentials from AWS STS, reads the three values into variables, and exports them — overriding the static credentials in your current terminal session.

Session duration

Temporary credentials are valid for limited timeframe. When they expire, repeat Step 3 and Step 5 to obtain new ones. You can customize the duration using the --duration-seconds parameter (minimum: 900 seconds).

You can now use the AWS CLI to access your environment:

aws ec2 describe-instances

Next steps

Security

Thu, 16 Jul 2026 13:50:17 +0000

This section explains how to check ECR image scan results and introduces the web application firewall: - [Checking ECR image scan results](/docs/ca/dev/security/check-ecr-image-scan-results.html) - [Web Application Firewall (WAF)](/docs/ca/dev/security/web-application-firewall-waf.html) You can also find some details on the [Regular patching activities](/docs/ca/dev/security/patching-maintenancewindows.html)

Environments overview

Thu, 16 Jul 2026 13:50:17 +0000

This document describes the environment types shipped with Spryker and the best ways to use them. Knowing the purpose of the environments and working with them as intended can help you build more solid and performant projects.

Contracts may vary, and this document only describes the environments types that may represent your default setup. If you are using a different setup, ask your project manager or product owner for a more detailed explanation.
Your non-production environments don’t scale automatically. If you want to increase their scaling, let us know by submitting this form: Upscale Request. Because of contractual reasons, only customers can request these changes, not partners.

Basic concept

We offer environments that serve different purposes. These environments are non-production, production-like, and production environments. We can configure these environments to be as similar as possible to make sure that the code you deploy in one environment behaves the same way as in the others. You can help us keep your environments consistent by taking this into consideration when sending us change requests.

Non-production environments (NON-PROD)

Used for development and testing purposes, smaller in size and doesn’t scale. We offer several types of NON-PROD environments as described in the following sections. Non-production environments don’t feature zero-downtime deployments because services, such as Yves or Glue, aren’t set up in a redundant manner.

Developer environment (DEV)

A Dev environment is a non-production environment that is usually used to test code that just left your development team, or is used in the development process directly through continuous deployment. It is not designed to handle load tests and large datasets. The development environment does not provide autoscaling and and can only be scaled up upon request.

Staging (STAGE)

This environment is a non-production environment that is usually used to host a snapshot of the DEV environment, or a stable version of your code that is deployed to production eventually. You can use your STAGE environment to test how your code behaves in a production environment. However, staging is not of the same size as production, and a subset of data and expected traffic must be considered while running tests. This environment is regularly used for demos. The staging environment provides limited autoscaling capabilities and can only be scaled up on request.

Production-like (PROD-LIKE)

This environment is set up exactly like a PROD environment. It’s designed to carry out temporary load testing and related activities in an environment similar to PROD. This makes deployments to PROD more predictable and prevents issues. PROD-LIKE behaves exactly like PROD, but it’s only available for a short time period to perform the necessary tests.

Production (PROD)

Your production environment hosts the code that the end-user gets to interact with directly. The code must already be tested on the STAGE environment for stability and performance. In a PROD Environment, the application is automatically scaled to handle the load on the infrastructure generated by incoming requests. Production environments also offer zero-downtime deployments of Spryker services, because Spryker services, such as Glue, Yves, and Back Office, are set up in a redundant manner, making sure there is always enough instances available to serve requests while others are updated.

Making changes on PROD

Before you deploy to PROD, make sure the changes were deployed and tested in your DEV and STAGE environments. We highly recommend testing every data load and import, as well as any integrations on your STAGE.

Next step

Connecting to AWS Console and CLI with an IAM user

Connecting to AWS CLI with an SSO user

Thu, 16 Jul 2026 13:50:17 +0000

This feature is part of a gradual rollout and will be available to everyone eventually. We will notify your team once your project is onboarded.

This document describes how to configure and use SAML2AWS to authenticate with the AWS CLI using your SSO credentials.

SAML2AWS is a command-line tool that lets you authenticate against an identity provider (IdP) using SAML and obtain temporary AWS credentials. This gives you AWS CLI access to your cloud environment without managing long-lived AWS access keys.

Prerequisites

SAML2AWS installed on your machine.
AWS CLI installed on your machine.
An SSO user. See User Management SSO.
Your SSO login page URL. To get it, see SSO Access.

Step 1: Configure SAML2AWS

To configure SAML2AWS, replace the placeholders with your actual values and execute the following:

saml2aws configure \
  --idp-provider=Browser \
  --browser-type={BROWSER_TYPE} \
  --url={YOUR_SSO_LOGIN_PAGE_URL} \
  --profile={YOUR_PROFILE} \
  --skip-prompt

Parameter	Description
`--idp-provider=Browser`	Uses a browser-based login flow via your identity provider.
`--browser-type`	The browser to use for authentication. See Supported browser types.
`--url`	SSO login page URL.
`--profile`	The AWS CLI profile name to store credentials under.
`--skip-prompt`	Skips interactive prompts and applies values directly.

Example:

saml2aws configure \
  --idp-provider=Browser \
  --browser-type=chrome \
  --url=https://auth.spryker.systems/realms/my-realm/protocol/saml/clients/my-aws-client \
  --profile=my-aws-profile \
  --skip-prompt

Step 2: Log in with SAML2AWS

After configuring, run the login command to authenticate and retrieve temporary AWS credentials:

saml2aws login \
  --profile={YOUR_PROFILE} \
  --skip-prompt

Add --force to skip the expiry check and re-authenticate even if existing credentials are still valid:

saml2aws login \
  --profile={YOUR_PROFILE} \
  --skip-prompt \
  --force

Browser driver

On some operating systems and browsers, SAML2AWS needs to download a browser driver automatically. If login fails or the browser does not open, add the --download-browser-driver flag:

saml2aws login \
  --profile={YOUR_PROFILE} \
  --download-browser-driver \
  --skip-prompt

You do not need this flag if you are on Linux and using Chrome.

On successful authentication, your terminal displays a confirmation and the credentials are saved under the specified profile.

Step 3: Use the AWS CLI

Pass --profile {YOUR_PROFILE} to any AWS CLI command to use the credentials obtained from SAML2AWS:

aws --profile={YOUR_PROFILE} s3 ls
aws --profile={YOUR_PROFILE} ec2 describe-instances

To avoid specifying --profile with every command, set the AWS_PROFILE environment variable for your session:

export AWS_PROFILE={YOUR_PROFILE}
aws s3 ls
aws ec2 describe-instances

The temporary credentials expire after a set period. When they expire, re-run the login command from Step 2 to refresh them.

Supported browser types

The --browser-type parameter accepts the following values (see the full list in the saml2aws source):

Value	Browser
`chrome`	Google Chrome (stable)
`chrome-beta`	Google Chrome Beta
`chrome-dev`	Google Chrome Dev
`chrome-canary`	Google Chrome Canary
`chromium`	Chromium
`firefox`	Mozilla Firefox
`webkit`	WebKit (Safari engine, macOS)
`msedge`	Microsoft Edge (stable)
`msedge-beta`	Microsoft Edge Beta
`msedge-dev`	Microsoft Edge Dev
`msedge-canary`	Microsoft Edge Canary

OS and browser combinations

The following combinations have been verified to work:

Operating system	Browser
Ubuntu	Chrome, Chromium, Firefox
macOS	WebKit, Chromium
Windows 10	Chrome, Firefox, Microsoft Edge

Chrome on macOS

Chrome on macOS may not work for all users. If you experience issues, use webkit or chromium instead.

Troubleshooting

Issue	Solution
The browser does not open during login.	Add `--download-browser-driver` to the login command to let SAML2AWS download the required browser driver automatically.
Authentication fails or credentials are not saved.	Verify that `--browser-type` matches a browser installed on your machine and that the `--url` value is correct.
The AWS CLI does not recognize the profile.	Ensure the `--profile` value in the login command matches the one used during configuration.
`Error authenticating to IDP.: please install the driver (vx.x.x) and browsers first: %!w(<nil>)`	Add `--download-browser-driver` to the login command to let SAML2AWS download the required browser driver automatically.

Next steps

Access

Thu, 16 Jul 2026 13:50:17 +0000

This section describes how to access AWS Management Console as an Identity and Access Management (IAM) user, locate the credentials for Spryker Cloud Commerce OS services, and connect to services:

Release notes 202604.0

Wed, 15 Jul 2026 13:21:24 +0000

Spryker Cloud Commerce OS is an end-to-end solution for digital commerce. This document contains a business-level description of new features and improvements. For information about installing Spryker, see [Getting started guide](/docs/dg/dev/development-getting-started-guide). ## B2B Business-Ready Commerce Experiences ### Back Office Configuration Framework is now Generally Available {% include badge.html type="feature" %} Spryker has made the Back Office Configuration Framework generally available, delivering key enterprise‑readiness improvements. The release enhances governance, discoverability, and usability for managing business‑relevant configuration directly in the Back Office. Configuration changes are now easier to understand, control, and audit. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/backoffice_framework.png||" %} **Key capabilities:** - Audit logging for configuration changes - Improved search and discoverability of configuration options - UX enhancements for a more reliable configuration experience - CLI-based import support for faster setup and operational workflows - Clear visibility into conflicts between code-based and Back Office configuration **Business benefits:** - Reduces time-to-change by enabling operations teams to adjust configuration without developer involvement, backed by a full audit trail. - Minimizes the risk of costly production disruptions through better validation and conflict visibility before changes go live. - Supports broader enterprise adoption with stronger governance and operability. **Documentation:** - [Back Office Configuration Framework](/docs/pbc/all/back-office/latest/base-shop/backoffice-configuration-framework.html) - [Developer Guide Configuration Management](/docs/dg/dev/backend-development/configuration-management) - [Install the Back Office Configuration Framework feature](/docs/dg/dev/integrate-and-configure/integrate-confguration-feature.html) ### Basic Shop Theming {% include badge.html type="feature" %} Business users can now manage core branding settings directly in the Back Office without code changes or deployments. This provides a standardized way to apply basic theming across Storefront, the Back Office, and Merchant Portal. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/theming_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/theming_2.png||" %} **Key capabilities:** - Supports theme management with global and store-specific scope. - Lets users upload and manage logos for Storefront, the Back Office, and Merchant Portal. - Provides configuration for core brand colors, button styles and text colors. - Uses a standardized Back Office configuration experience for theme administration. **Business benefits:** - Speeds up demo preparation, POCs, and early customer activation through instant, self-service branding configuration. - Shop operators can now apply and adjust their brand CI across all Spryker touchpoints at any time directly in the Back Office, without developer involvement or redeployment. **Documentation:** - [Feature Overview](/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/purchasing-control-feature-overview.html) - [Installation Guide](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-purchasing-control-feature.html) ### Budget & Cost Centers {% include badge.html type="feature,early-access" %} We introduced an Early Access version of budgets and cost centers to support policy-driven purchasing in B2B procurement. The release covers core budget enforcement and its integration with approval workflows. **Key capabilities:** - Lets companies create and manage cost centers and assign buyers to them. - Supports budget creation with configurable enforcement rules such as block, warn, or require approval. - Adds cost center selection and budget validation during checkout. - Integrates budget-triggered approvals with Spryker's existing Approval Process. - Tracks budget consumption and restoration as orders progress. **Business benefits:** - Improves financial control and purchasing compliance. - Reduces overspending risk with enforceable budget rules. - Aligns procurement workflows with departmental or project-based spending structures. - Provides an early demoable foundation for customer and partner conversations. **Documentation:** - [Purchasing Control Feature Overview](/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/purchasing-control-feature-overview) - [Install Purchasing Control Feature Overview](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-purchasing-control-feature) ### Back Office Product Import & Export {% include badge.html type="feature,early-access" %} Spryker now offers product import and export via the Back Office, reducing reliance on developer‑driven CLI tooling. Business users can prepare and update catalogs faster during onboarding, launches, and routine maintenance. This improves operational speed and gives teams more control over their product data processes. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/bo_import_export_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/bo_import_export_2.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/bo_import_export_3.png||" %} **Key capabilities:** - Import and export product data directly from the Back Office - Single‑file product import, replacing multiple CLI‑required files - CSV‑based jobs with reusable job/run concepts and clear validation feedback **Business benefits:** - Significantly simplifies adding products to the catalog, replacing multi‑file CLI imports with a single, business‑friendly file - Accelerates catalog preparation for new launches and environment migrations - Empowers business users with self‑service error resolution, minimizing developer involvement **Documentation:** - [Product Experience Management](/docs/pbc/all/product-experience-management/latest/product-experience-management.html) - [Install the Product Experience Management feature](/docs/pbc/all/product-experience-management/latest/install-the-product-experience-management-feature.html) ### Product attribute display types {% include badge.html type="feature" %} You can now control where product attributes are visible without project-specific customization. This helps keep internal operational data hidden while displaying only relevant information to buyers. **Key capabilities:** - Adds visibility types for product attributes. - Supports internal-only attributes as well as attributes shown on PDP, PLP, and cart-related experiences. - Provides native configuration for attribute visibility management. **Business benefits:** - Shop operators can now control which attributes are displayed where across the storefront, making it easier to surface the right product information at the right place to support buyer decision-making and product discovery. - Internal attributes can be managed separately to support operational or process-related needs without ever being exposed to buyers. **Documentation:** - [Product Attribute Display Types](/docs/pbc/all/product-information-management/latest/base-shop/feature-overviews/product-feature-overview/product-attribute-visibility-overview) - [Install Product Attribute Visibility Feature](/docs/pbc/all/product-information-management/latest/base-shop/install-and-upgrade/install-features/install-the-product-attribute-visibility-feature) ### Spryker Storefront Design System Foundation {% include badge.html type="feature" %} Building storefronts without a common foundation meant repeated work, slower delivery, and experiences that looked and felt different every time. This release introduces a unified design system with shared foundations and reusable components, so teams work from common building blocks. The result is faster implementation, easier adoption, and the ability to scale storefront delivery without scaling complexity. **Key capabilities:** - Defines the design system foundation with shared tokens and naming conventions. - Introduces token-driven implementation patterns for new storefront components. - Adds composite component patterns built from core UI elements. - Covers common structures such as cards, buttons, input fields, headers, search and more. **Business benefits:** - Improves consistency across storefront experiences. - Reduces duplicate design and frontend implementation effort. - Accelerates feature delivery with reusable UI patterns. - Creates a stronger foundation for future storefront evolution. **Documentation:** - [How to use design system tokens](/docs/dg/dev/frontend-development/latest/design-tokens#how-it-works) ### Back Office support for merchant product ownership {% include badge.html type="improvement" %} Marketplace operators can now manage merchant ownership of products directly in the Back Office, without relying on the Merchant Portal. This makes it easier to maintain accurate product data in centrally managed or hybrid marketplace models. The result is smoother operations and clearer accountability across the catalog. **Key capabilities:** - Assign or update merchant ownership for any product directly in Back Office workflows. - See merchant ownership instantly within product management views. - Maintain merchant‑related product data as part of your standard PIM processes. **Business benefits:** - Strengthens support for centrally managed catalogs and hybrid marketplace models, giving operators more flexibility in how they run their marketplace. - Improves transparency and control, making ownership clear, consistent, and auditable. - Reduces reliance on workarounds and custom tooling, lowering operational overhead. - Supports more flexible marketplace operations, enabling teams to scale product management with confidence. **Documentation:** - [Marketplace Create Abstract Products](/docs/pbc/all/product-information-management/latest/marketplace/manage-in-the-back-office/products/abstract-products/create-abstract-products#defining-general-settings) ### Back Office Frontend Modernisation {% include badge.html type="improvement" %} We delivered the first phase of the Back Office theme modernisation to improve clarity, consistency, and responsiveness. This update creates a more usable and scalable visual foundation without changing the overall information architecture. **Key capabilities:** - Improves visual hierarchy and component consistency across the Back Office. - Reduces UX debt introduced by legacy Inspinia defaults. - Enhances spacing, density, emphasis, and table presentation. - Provides a more stable foundation for future Back Office UX improvements. **Business benefits:** - Improves daily usability for Back Office users. - Makes the Back Office more credible and demo-ready. - Reduces the need for one-off CSS customizations. - Establishes a better base for future product evolution. ### Streamlined Login and Session Recovery Experience {% include badge.html type="improvement" %} Logging in should feel like picking up where you left off, not starting over. With this release, users across the Back Office, Storefront, and Marketplace are presented with a meaningful dashboard featuring quick actions for common tasks, including viewing orders, adding products, and checking returns. After a session timeout, users are redirected back to the page they were on so they do not lose track of what they were doing. **Key capabilities:** - Redirects Back Office users to the dashboard instead of a blank technical page after login. - Adds action-oriented quick actions to the Back Office dashboard for common tasks such as viewing orders, adding products, opening the catalog, and checking returns. - Restores the last visited page after session timeout across the Back Office, Storefront, and Marketplace. - Reopens create and edit pages after re-login, while unsaved data is not preserved. **Business benefits:** - Reduces onboarding friction for new users. - Helps operational users continue workflows faster after session expiration. - Improves usability and perceived product maturity across core daily journeys. - Makes demos and first-touch product experiences more intuitive. ## Connected, and AI-Enabled Platform ### Spryker Now Ships with AI Foundation and Smart Product Enrichment {% include badge.html type="improvement,early-access" %} Spryker now includes the AI Foundation and Smart PIM out of the box, allowing merchants to adopt AI‑assisted catalog enrichment with minimal setup. Product content can be improved, translated, and enriched directly in the Back Office using AI, reducing manual work and improving content quality. Customers only need to connect their preferred AI provider to start benefiting from AI‑powered product enhancements, with governance automatically handled through AI Foundation. **Key capabilities** - Enhances and translates product names and descriptions using AI - Generates alt‑text for product images and suggests suitable product categories - Delivered by default in Spryker, requiring only AI provider configuration **Business benefits** - Reduces manual effort in creating and refining product content across the catalog - Makes AI adoption easier by providing a pre‑configured integration layer with built‑in governance and provider flexibility - Speeds up catalog enrichment and localization for merchants operating across multiple markets **Documentation** - [AI Foundation Overview](/docs/dg/dev/ai/ai-foundation/ai-foundation-module) - [Smart PIM](/docs/pbc/all/ai-commerce/latest/smart-pim) ### Smart Back Office Assistant {% include badge.html type="feature,early-access" %} Spryker introduces the Smart Back Office Assistant, enabling operators to perform Back Office tasks through natural language instead of relying solely on manual navigation. Operators can get guidance on where to find features, ask operational and order‑related questions, and create discounts directly through chat. This makes Back Office work faster, more intuitive, and easier for all user types. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/bo_ai_assistant.png||" %} **Key capabilities** - Provides navigation and operational guidance to help users quickly find functions and understand Back Office workflows - Answers order‑related questions, including order status and operational details - Assists to complete forms, for example, by enabling discount creation directly through chat. **Business benefits** - Reduces time spent searching for pages and completing repetitive tasks - Improves usability for operators who are less familiar with Back Office structure or workflows - Helps prevent errors by guiding operators through correctly structured inputs and actions **Documentation** - [Back Office Assistant](/docs/dg/dev/ai/ai-commerce/ai-commerce-overview.html) - [Install Back Office Assistant](/docs/dg/dev/ai/ai-commerce/backoffice-assistant/install-backoffice-assistant.html) ### AI Foundation Visibility & Governance Enhancements {% include badge.html type="feature,early-access" %} Spryker introduces comprehensive visibility into AI activity through new Back Office views for both AI interactions and AI workflow execution. Teams can now inspect prompts, responses, metadata, and workflow states in a single place, improving transparency and control over AI‑driven processes. These enhancements strengthen governance, streamline troubleshooting, and make AI operations easier to understand and monitor. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/bo_ai_auditlogs_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/bo_ai_auditlogs_2.png||" %} **Key capabilities:** - Back Office audit logs for reviewing prompts, responses, metadata, and model details - Workflow execution views with list, detail, state history, and visualized transitions - Filtering, sorting, and inline inspection tools for efficient debugging and analysis **Business benefits:** - Improves governance and traceability across all AI‑powered processes - Simplifies troubleshooting by making AI interactions and workflow states fully transparent - Gives operators greater control over AI‑driven actions with clear visibility into execution paths **Documentation:** - [AI Foundation Audit Logs](/docs/dg/dev/ai/ai-foundation/ai-foundation-audit-logs.html) - [AI Foundation Workflows](/docs/dg/dev/ai/ai-foundation/ai-foundation-workflow-state-machine) ### Smart Visual Product Search & Ordering {% include badge.html type="improvement,early-access" %} Spryker now enables buyers to identify products and start orders simply by uploading or capturing an image. Whether it's a technical part, a field-site photo, or a handwritten note, the system can recognize products and quantities and help buyers move directly from identification to ordering. The entire capability now runs on the Spryker AI Foundation, offering provider flexibility, improved reliability, and easier long‑term adoption. **Key capabilities** - Helps buyers identify relevant or visually similar products by uploading or capturing an image - Prefills the quick order form with products and quantities extracted from photos, screenshots, or handwritten notes - Uses Spryker AI Foundation for multi‑provider support (OpenAI, Azure, Bedrock) and centralized AI governance **Business benefits** - Speeds up product identification and ordering, especially for technical and spare‑parts workflows - Reduces manual entry and ordering errors by interpreting product information directly from images - Supports mobile and field‑based buying scenarios where buyers capture photos instead of searching by name or SKU **Documentation** - [Search by Image](/docs/pbc/all/ai-commerce/latest/search-by-image) - [Visual Add to Cart](/docs/pbc/all/ai-commerce/latest/visual-add-to-cart) - [Install Search by Image](/docs/dg/dev/ai/ai-commerce/search-by-image/install-search-by-image) - [Install Visual Add to Cart](/docs/dg/dev/ai/ai-commerce/visual-add-to-cart/install-visual-add-to-cart) ### AI Dev Tooling for Coding Agents {% include badge.html type="feature,early-access" %} Spryker now provides ready-to-use new AI Dev tooling to help development teams work more effectively with coding agents in Spryker projects. The update provides ready-to-use agent instruction files and reusable Spryker-specific skill examples. **Key capabilities:** - Generates a project‑ready agent configuration file (AGENTS.md) - Generates a set of rules for AI agent based on Spryker coding conventions and architectural guidelines - Provides reusable skill examples covering testing, data import, schema conventions, validation, and frontend development - Includes a setup command that generates agent configuration file, rules and skills for supported coding agents **Business benefits:** - Speeds up onboarding for developers who are new to Spryker by giving AI coding agents the right context from day one - Improves code quality and consistency through pre‑written, Spryker‑aligned development rules - Helps teams deliver features faster by reducing back‑and‑forth with AI tools and minimizing incorrect code generation **Documentation:** - [AI Dev SDK](/docs/dg/dev/ai/ai-dev/ai-dev-overview) ### API Platform is now Generally Available {% include badge.html type="feature" %} Spryker made API Platform generally available as the foundation for modern API development and migration. Existing APIs have been migrated to API Platform internally while keeping external contracts backward-compatible. This enables faster API delivery, easier extensibility, and more standardized API development. ![API Platform](https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202512/api-platform-2.6-api.png) **Key capabilities:** - Declarative API development using YAML schemas - API generation with validation, pagination, serialization, and operation-specific rules - Interactive and always up-to-date OpenAPI documentation - Backward-compatible migration of existing APIs to API Platform infrastructure - Cleaner separation of read and write logic through providers and processors **Business benefits:** - Reduces development effort for new and existing APIs - Improves consistency and maintainability of API implementations - Accelerates delivery of integrations and future API capabilities **Documentation:** - [API Platform](/docs/dg/dev/architecture/api-platform.html) - [Migration Status of out-of-the-box API Endpoints](/docs/dg/dev/architecture/api-platform/migrate-to-api-platform-status.html) ### Algolia configuration in the Back Office {% include badge.html type="improvement" %} Spryker updated the Algolia integration settings in the Back Office to replace the legacy ACP-based configuration experience. The new page uses the Back Office Configuration Framework and provides a more consistent and user-friendly way to manage Algolia credentials. This helps reduce setup effort and simplifies validation during implementation. **Key capabilities:** - New configuration section in **Back Office > Configuration > Integrations > Algolia** - Manage Algolia credentials, including: - Application ID - Search-only API key - Admin API key - Validate credentials directly via API calls - Align Algolia setup with the current Spryker-native integration approach **Business benefits:** - Simplifies Algolia setup and maintenance in the Back Office - Reduces implementation time and configuration errors - Replaces legacy ACP-era fields with a clearer configuration experience **Documentation:** - [Integrate Algolia](/docs/pbc/all/search/latest/base-shop/third-party-integrations/algolia/integrate-algolia) ### Mollie PSP Integration {% include badge.html type="feature" %} Spryker introduces a new native integration with Mollie, a leading European payment service provider, enabling seamless B2B and B2C payment experiences across key European markets. The integration allows merchants to quickly enable a wide range of local and international payment methods with minimal development effort. It is delivered in collaboration with Spryker Solution Partner KPS. **Key capabilities:** - Native integration with Mollie - Support for a wide range of local European and international payment methods - Plug-and-play setup with minimal custom development **Business benefits:** - Faster time-to-market for European commerce use cases - Improved conversion through localized payment experiences - Reduced implementation complexity and maintenance overhead **Documentation:** - [Mollie integration](https://github.com/mollie/spryker) ### OAuth SSO readiness for Spryker applications {% include badge.html type="feature" %} Spryker introduced a standardized and reusable approach for OAuth 2.0 and OpenID Connect single sign-on across key applications. The release establishes a consistent integration pattern for identity providers such as Keycloak, Azure AD, and Okta for the Back Office, Storefront, and Merchant Portal. This makes identity integrations more predictable and reduces the need for project-specific implementations. **Key capabilities:** - Standardized SSO approach for: - the Back Office - Storefront - Merchant Portal - Support for OAuth Authorization Code flow with PKCE - Provider-agnostic integration based on configurable OAuth providers - Persistent identity linking between external providers and Spryker users - Reference implementation, templates, configuration patterns, and rollout guidance - Backward compatibility with existing form-based login **Business benefits:** - Reduces time and cost for enterprise identity integrations - Improves implementation predictability across projects - Creates a reusable foundation for federated authentication across Spryker entry points **Documentation:** - [Federated Authentication via OAuth2/OIDC](/docs/pbc/all/oauth/latest/federated-authentication.html) ### Native PunchOut Gateway for cXML and OCI {% include badge.html type="feature,early-access" %} Spryker introduced native PunchOut Gateway capabilities for cXML and OCI to reduce bespoke integration work in procurement-driven B2B commerce. The release adds reusable building blocks for common PunchOut flows, including session start, shopping, cart updates, and cart return. This strengthens support for enterprise procurement environments, especially SAP-centric setups. **Key capabilities:** - Native compatibility for cXML and OCI PunchOut scenarios - Support for basic PunchOut requisition and cart flows - Standard OCI parameter handling - OCI cart return support with line items - Reusable message handling and implementation guidance **Business benefits:** - Reduces custom development effort for PunchOut implementations - Speeds up procurement-channel enablement and time-to-revenue - Improves repeatability and maintainability across B2B integration projects **Documentation:** - [PunchOut Gateway](/docs/pbc/all/punchout-gateway/punchout-gateway)

### New Stripe Integration {% include badge.html type="improvement" %} Spryker introduced a new Stripe integration that replaces the legacy ACP-based app with a more extensible Spryker-native implementation. The release also adds a dedicated configuration page in the Back Office for managing Stripe settings. This gives customers and partners more control over Stripe-based payment flows and reduces dependency on legacy integration boundaries. **Key capabilities:** - New installable Stripe Eco module without ACP runtime dependency - Support for checkout payment method selection - Support for payment initialization, authorization, capture, refund, and cancel flows - New configuration section in **Back Office > Configuration > Integrations > Stripe** - Validation of Stripe keys and webhook configuration - Storage of Stripe settings in configuration storage **Business benefits:** - Improves flexibility for extending and customizing Stripe payment flows - Reduces implementation risk and legacy dependency overhead - Lowers long-term maintenance effort and supports faster payment innovation **Documentation:** - [New Stripe Integration](https://github.com/spryker-eco/stripe/releases/tag/1.0.0) ### New Vertex Integration {% include badge.html type="improvement" %} Spryker introduced a new Vertex integration to replace the legacy ACP-based approach for tax calculation scenarios. The new integration is designed to provide more flexibility and reduce legacy constraints when adapting tax-related processes. This supports more maintainable and extensible tax integrations over time. **Key capabilities:** - New Spryker-native Vertex integration - Reduced reliance on legacy ACP-based architecture - Improved extensibility for tax calculation and related scenarios **Business benefits:** - Supports more adaptable tax integrations for changing business needs - Reduces integration friction and project-specific patching - Lowers total cost of ownership through improved maintainability **Documentation:** - [Integrate Vertex](/docs/pbc/all/tax-management/latest/base-shop/third-party-integrations/vertex/install-vertex/integrate-vertex) ### Data import performance and stability enhancements {% include badge.html type="improvement" %} We improved the data import experience and robustness for large data volumes. Data imports now provide better execution visibility through a progress bar, and memory usage has been optimized to better support very large imports, including merchant price imports with up to 1 million records. **Key capabilities:** - Added a progress bar for data import console commands to show execution progress. - Reduced memory consumption in data import flows to prevent out-of-memory issues during large imports. - Improved reliability for high-volume imports across data import entities. **Business benefits:** - Helps operators better monitor long-running imports. - Reduces failures caused by memory exhaustion during large imports. - Improves operational efficiency for bulk data onboarding. **Documentation:** - [Data import (memory usage)](/docs/dg/dev/guidelines/performance-guidelines/keeping-dependencies-updated.html#data-import-memory-usage) - [Data import Progress bar](/docs/dg/dev/data-import/latest/data-import-optimization-guidelines.html#progress-bar) ### Performance and security improvements {% include badge.html type="improvement" %} We made your Spryker Commerce OS faster, more secure, and more stable. **Key capabilities:** - Non-buffered log streaming presents the logs immediately. - Lower latency and response times in storefront with optimized widgets. - Lower latency and response times in the Back Office and Merchant Portal. - Higher stability and throughput of Publish & Synchronize workers. The update introduces dynamic waiting behavior, better control over parallel job execution, and compatibility improvements for Symfony Messenger resource-aware workers. **Documentation:** - [Non-buffered log streaming](https://api.release.spryker.com/release-group/6411) - [Yves widget performance best practices](/docs/dg/dev/guidelines/performance-guidelines/yves-performance-best-practice.html) - [Split Publish & Synchronize queues for performance](/docs/dg/dev/guidelines/performance-guidelines/split-queues-performance.html) - [Merchant Portal and Back Office performance with ACL rules](/docs/dg/dev/guidelines/performance-guidelines/keeping-dependencies-updated.html#merchant-portal-and-back-office-performance-with-acl-rules) - [Order details page performance guidance](/docs/pbc/all/order-management-system/latest/base-shop/order-management-feature-overview/order-details-page-performance-overview.html) ## Efficient and Flexible Cloud Foundation ### Spryker Monitoring Integration: logs forwarding {% include badge.html type="improvement" %} Spryker expanded cloud observability by enabling log forwarding through [SMI](/docs/ca/dev/monitoring/spryker-monitoring-integration/spryker-monitoring-integration.html) to third-party monitoring platforms of your choice. This allows teams to correlate logs with traces, create alerts based on log data, and use their preferred monitoring tooling beyond AWS CloudWatch. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/SMI-dynatrace-logs.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202604/SMI-dynatrace-traces.png||" %} **Key capabilities:** - Inspect logs from Spryker Platform in your monitoring tool - Correlate logs with traces using trace and span identifiers - Configure log verbosity to control emitted log volume **Business benefits:** - Improved troubleshooting through unified logs and traces - Better alerting capabilities based on application and infrastructure log events **Documentation:** - [Spryker Monitoring Integration Logs](/docs/ca/dev/monitoring/spryker-monitoring-integration/opentelemetry-instrumentation#smi-logs-integration) ### Single Sign-On (SSO) for Cloud services {% include badge.html type="feature" %} Spryker introduced centralized access management for cloud services, including SSO support for customer identity providers such as Okta and OneLogin. This update reduces manual access handling, improves security, and simplifies onboarding and offboarding for users. It also includes rollout, production-readiness, and IAM cleanup measures to standardize and harden access controls.

**Key capabilities:** - Connect your own identity provider for SSO access to cloud services - Centralize user access management for services such as Jenkins, RabbitMQ, and others - Reduce manual access management effort through self-service-oriented processes **Business benefits:** - Faster and more secure user onboarding and offboarding - Reduced operational effort for access requests and changes - TLS-encrypted communication to Jenkins and RabbitMQ over internal environment network **Documentation:** - [Spryker Cloud SSO Access](/docs/ca/dev/access/sso-access.html) ### Bastion security hardening {% include badge.html type="improvement" %} Spryker improved Bastion host security and maintainability by upgrading the operating system, isolating workloads from the host, and enforcing SSO and MFA for human access. This change modernizes the setup while keeping customer impact minimal and preserving SFTP access for integrations. **Key capabilities:** - Upgrade Bastion hosts to a current LTS operating system - Enforce SSO and MFA for human access, deprecate direct SSH access for human users **Business benefits:** - Improved security posture for administrative access ### Maintenance and service updates {% include badge.html type="improvement" %} Spryker delivered maintenance updates across cloud services and application tooling to keep the platform secure, supported, and maintainable. **Key capabilities:** - RabbitMQ 4.2 is now supported in Docker SDK for local development environments. - Node.js 24 introduces V8 v13.6 and npm 11, which results in noticeably faster `frontend:yves:build` and `frontend:zed:build` runs. **Business benefits:** - Reduced security and operational risk from outdated components **Documentation:** - [RabbitMQ 4.2 in Docker SDK](/docs/dg/dev/sdks/the-docker-sdk/the-docker-sdk.html) - [Upgrade Node.js and npm](/docs/dg/dev/upgrade-and-migrate/upgrade-nodejs.html#prerequisites)

Release notes 202606.0

Wed, 15 Jul 2026 12:09:00 +0000

### Search Statistics & Google Analytics {% include badge.html type="feature" %} Search Statistics brings native search analytics to the Back Office for customers using ElasticSearch. Business users can review frequent searches and zero-result searches to better understand buyer behavior and optimize product discovery. **Key capabilities:** - View top frequent searches and top zero-result searches in the Back Office - Filter analytics by time period and review detailed search data - Export search statistics to Google Analytics for further analysis and sharing **Business benefits:** - Reduces the need for custom project-specific search analytics implementations - Helps teams improve search relevance, synonyms, and catalog quality based on real data - Identifies search gaps that can negatively affect discoverability and conversion **Documentation:** - [Search Statistics Feature Overview](/docs/pbc/all/miscellaneous/latest/third-party-integrations/marketing-and-conversion/analytics/google-analytics/search-statistics) - [Install Search Statistics](/docs/pbc/all/miscellaneous/latest/third-party-integrations/marketing-and-conversion/analytics/google-analytics/install-search-statistics) ### Back Office usability improvements {% include badge.html type="improvement" %} We improved several Back Office interactions to make administration tasks clearer and less error-prone. This covers block and slot assignment validation. **Key capabilities:** - Restores validation feedback when saving block and slot assignments - Fixes missing menu highlight on the View Merchant page in the Back Office **Business benefits:** - Improves clarity during Back Office administration - Helps business users navigate merchant management more easily **Releases:** - [No validation errors when saving block + slot assignment](https://api.release.spryker.com/release-group/6509) ### PunchOut support in the Back Office {% include badge.html type="improvement" %} PunchOut support in the Back Office makes PunchOut integrations easier to configure and manage with a more low-code approach. Building on Spryker's native support for common PunchOut flows and cXML/OCI compatibility, this update adds a dedicated PunchOut section with relevant fields and configuration support. This helps solution teams deliver integrations with less custom development effort. **Key capabilities:** - Adds a dedicated PunchOut section in the Back Office - Supports configuration of relevant PunchOut integration fields in a more low-code way - Complements native cXML, OCI, and core PunchOut message handling capabilities **Business benefits:** - Reduces bespoke development effort for PunchOut integrations - Makes implementations more repeatable and faster across projects - Simplifies setup and maintenance for customers and implementation partners

**Documentation:** - [PunchOut Gateway](/docs/pbc/all/punchout-gateway/punchout-gateway.html) ### PunchCommerce Punchout Connector {% include badge.html type="feature" %} The PunchCommerce Punchout Connector extends Spryker's support for complex PunchOut scenarios through a partner integration. It is designed for use cases that require multiple eProcurement connectors and document handling beyond Spryker's native capabilities. This helps customers address more advanced procurement integration requirements. **Key capabilities:** - Connects Spryker with PunchCommerce for advanced PunchOut scenarios - Supports use cases with multiple eProcurement connectors - Adds support for document-handling requirements not covered by native capabilities **Business benefits:** - Broadens PunchOut coverage for more complex B2B procurement scenarios - Reduces the need for bespoke implementations in advanced projects - Expands ecosystem support through a specialized partner solution **Documentation:** - [https://gitlab.netzdirektion.de/packages/punchcommerce-spryker-module](https://gitlab.netzdirektion.de/packages/punchcommerce-spryker-module) ## Connected, and AI-Enabled Platform ### AI Dev SDK: AI-Assisted Customization for Spryker Projects {% include badge.html type="early-access" %} The AI Dev SDK helps teams customize Spryker projects faster and with less manual effort. It supports developers in generating quick proofs of concept and MVP customizations that follow Spryker's patterns and project conventions, with developers staying in control at each approval point. This helps teams validate ideas faster, keep customization quality more consistent, and lower the manual effort each one takes.

**Key capabilities:** - Orchestrates the full Spryker customization workflow, from research and planning through code generation, testing, and verification, with self-correction when issues are detected and developer approval at key checkpoints - Automates the technical work needed after every code change, including database migrations, cache rebuilds, and frontend builds - Offers two quality levels: quick PoC for validating ideas fast, and MVP for delivering code that follows Spryker's canonical patterns and project conventions **Business benefits:** - Speeds up delivery of Spryker customizations, whether a quick proof of concept or an MVP-grade build. - Reduces development effort and catches issues against Spryker and project standards earlier. - Lowers the cost of experimentation — quick PoCs make it cheap to validate an idea before investing in a full implementation. **Documentation:** - [AI Dev SDK Skills and Agents](/docs/dg/dev/ai/ai-dev/ai-dev-skills-and-agents.html) - [AI Dev SDK Customization Workflow](/docs/dg/dev/ai/ai-dev/ai-dev-customization-workflow.html) - [Claude Code Plugin](/docs/dg/dev/ai/ai-dev/ai-dev-claude-code-plugin.html) ### AI Commerce: Smart CMS for AI-assisted content creation {% include badge.html type="early-access" %} Smart CMS brings AI assistance directly into the CMS page and block creation in the Back Office. Content editors and business users can generate structured text content in-flow instead of writing or copying content manually. This reduces the effort required to create and update commerce content experiences at scale. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_smart_cms_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_smart_cms_2.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_smart_cms_3.png||" %} **Key capabilities:** - Generates CMS page and block content directly in the Back Office authoring flow - Accepts source attachments, such as documents with customer questions, to generate structured content like FAQ pages - Understands Spryker-specific content items so generated content fits existing content structures **Business benefits:** - Reduces manual effort for routine content creation and updates - Improves productivity for content editors and business admins - Helps scale content operations more efficiently as content needs grow **Documentation:** - [Smart CMS Content Assistant](/docs/pbc/all/ai-commerce/latest/smart-cms-content-assistant) - [Install Smart CMS Content Assistant](/docs/dg/dev/ai/ai-commerce/content-assistant/install-smart-cms-content-assistant#prerequisites) ### AI Foundation: Back Office AI Configuration {% include badge.html type="early-access" %} AI Foundation now includes a unified configuration experience in the Back Office for managing AI providers, models, prompts, and feature-specific behavior. This gives business and operational users a clearer, more consistent way to activate and control AI-powered capabilities, including switching AI vendors or models on the fly, without developer involvement or redeployment. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_configuration_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_configuration_2.png||" %} **Key capabilities:** - Centralizes AI provider and credential management in one configuration area - Supports feature-level enablement and control of AI behavior, including AI vendor, model, and prompt configuration, with no code changes or deployments required - Provides an extensible foundation designed to support additional AI-powered features over time **Business benefits:** - Simplifies setup and onboarding for AI-powered features - Gives merchants more control over AI behavior, output quality, and governance - Reduces configuration errors and repetitive administrative work **Documentation:** - [Configure multiple AI providers for AI Commerce](/docs/dg/dev/ai/ai-commerce/configure-multiple-ai-providers) ### AI Foundation: Back Office AI Cost Estimator {% include badge.html type="early-access" %} The AI Cost Estimator adds estimated AI cost visibility to the AI Audit Logs in the Back Office. Admins can configure model pricing once and then see estimated costs per interaction, total estimated spend, and breakdowns by provider and model. This makes it easier to understand the cost of individual AI-powered commerce features and make informed decisions about their value and continued use. {% include carousel.html images=" https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_cost_estimator_1.png||:: https://spryker.s3.eu-central-1.amazonaws.com/docs/About/Releases/release-notes-202606/bo_ai_cost_estimator_2.png||" %} **Key capabilities:** - Shows estimated cost per AI interaction in the Audit Logs page - Provides total estimated cost and provider and model-level cost breakdowns based on active filters - Uses customer-configured provider and model prices, including support for multiple currencies **Business benefits:** - Improves visibility into AI operating costs across commerce features - Supports better governance and value assessment of AI capabilities - Reduces manual work previously needed to estimate AI spend from token usage **Documentation:** - [AI Audit Logs & Cost Estimations](/docs/dg/dev/ai/ai-foundation/ai-foundation-audit-logs) ### GLUE REST API migration to API Platform {% include badge.html type="feature" %} Spryker has modernized its internal GLUE REST API infrastructure by migrating it to API Platform. This change is backward compatible for existing API clients, while making APIs easier to maintain, extend, and evolve internally. It also improves the foundation for delivering new endpoints and capabilities faster. **Key capabilities:** - Keeps existing external API contracts unchanged for current clients and consumers - Replaces custom internal API infrastructure with API Platform - Enables more standardized API generation, validation, and documentation **Business benefits:** - Accelerates API delivery and reduces development effort for new endpoints - Improves maintainability and extensibility of the API layer - Supports more consistent and predictable machine-to-machine integrations **Documentation:** - [API Strategy](/docs/integrations/spryker-glue-api/getting-started-with-apis/api-strategy.html) - [Spryker API roadmap and adoption](/docs/integrations/spryker-glue-api/getting-started-with-apis/api-roadmap-and-adoption#whats-on-the-roadmap.html) - [Storefront API B2B Demo Shop reference](/docs/integrations/spryker-glue-api/storefront-api/api-references/storefront-api-b2b-demo-shop-reference.html) ### Backend API added to the Spryker API Strategy {% include badge.html type="feature" %} Spryker extended its API strategy to cover the Backend API, the application for administrative and system-to-system integrations. The strategy now documents the API types available under the Backend API—starting with the Back Office API you can build on today—and the types planned on the roadmap, all built on API Platform integration. As with the rest of the strategy, existing Glue Backend APIs remain fully supported with no End-of-Life and no forced migration. **Key capabilities:** - Documents the Backend API application and its API types, and clarifies that the Backend API application is distinct from the Back Office API type - Back Office API is available today for administrator-level and trusted internal integrations - Roadmap types documented for planning: Merchant API, Merchant Data Exchange API, Data Exchange API, and Async Event API - Guidance for choosing a Backend API type by caller and data-flow shape—record-by-record, bulk, or event-driven **Business benefits:** - Gives a clear, forward-looking view of backend integration options across administration, merchant, data exchange, and events - Protects existing Glue Backend API investments with a no-End-of-Life, no-forced-migration commitment - Speeds up planning for ERP, PIM, OMS, and marketplace integrations with consistent guidance **Documentation:** - [Spryker API Strategy](/docs/integrations/spryker-glue-api/getting-started-with-apis/api-strategy.html) - [Spryker API roadmap and adoption](/docs/integrations/spryker-glue-api/getting-started-with-apis/api-roadmap-and-adoption.html) ## Efficient and Flexible Cloud Foundation ### Propel 2.0 LTS {% include badge.html type="improvement" %} This work includes advancing Propel toward a stable release and increasing active maintenance. **Documentation:** - [PropelORM](https://github.com/propelorm/Propel2/releases/tag/2.0.0) ### Maintenance and service updates {% include badge.html type="improvement" %} We rolled out regular maintenance and service updates across cloud components to keep environments secure, stable, and maintainable. This includes updates to core services and supporting infrastructure components. These changes help reduce operational risk and technical debt over time. **Key capabilities:** - Updates core services and infrastructure components such as Nginx 1.30, and Docker images - Improves long-term maintainability of cloud services - Updated multiple dependencies **Business benefits:** - Improves system reliability and operational resilience - Updates `shell-quote` to a patched version addressing a critical shell injection vulnerability. - Upgrades `symfony/runtime` to address unsafe request argument handling. - Upgrades `symfony/monolog-bridge` to address unauthenticated log listener exposure. **Documentation:** - [Docker Images](/docs/about/all/releases/image-releases/spryker-php/release-notes-spryker-php-20260608.html) ### Key-Value Storage Optimization for Dynamic Store Mode {% include badge.html type="improvement" %} We optimized key-value storage usage for Dynamic Store Mode to reduce duplicated data across store and locale combinations. This improvement lowers Valkey/Redis memory consumption and key volume while keeping the solution backward compatible and opt-in. It is especially valuable for deployments with multiple stores and locales. **Key capabilities:** - Reduces duplicated product abstract and URL storage data in Dynamic Store Mode - Keeps compatibility with existing storage formats and supports gradual adoption - Provides an opt-in configuration and migration path for controlled rollout **Business benefits:** - Improves scalability for multi-store and multi-locale setups - Helps delay or avoid costly cache instance size increases **Documentation:** - [KV Storage Deduplication](/docs/dg/dev/guidelines/performance-guidelines/kv-storage-deduplication.html) ### Queue processing resilience and worker behavior {% include badge.html type="improvement" %} We improved queue processing behavior to reduce the risk of blocked or stalled message handling. The update addresses long-running worker processes, retry queue handling, and premature worker exits while messages are still waiting. **Key capabilities:** - Improves handling of long-running or stuck queue worker child processes - Prevents failed messages from being lost when no retry queue exists - Ensures `queue:worker:start --stop-when-empty` behaves more reliably **Business benefits:** - Reduces the risk of blocked publish and processing pipelines - Improves operational stability for queue-based workloads - Helps teams recover from processing failures more predictably **Documentation:** - [Publish and synchronization (queue and event performance)](/docs/dg/dev/guidelines/performance-guidelines/keeping-dependencies-updated#publish-and-synchronization-queue-and-event-performance) - [Enable queue worker wait limit](/docs/dg/dev/guidelines/performance-guidelines/general-performance-guidelines#enable-queue-worker-wait-limit) ### Cloud security improvements {% include badge.html type="improvement" %} We delivered a set of cloud security improvements to strengthen infrastructure protection and reduce unnecessary access paths. These updates address container-to-instance access risks, improve IAM controls, and support more secure cloud operations. They also include compatibility adjustments for newer managed service defaults. **Key capabilities:** - Tightens IAM policy controls to prevent overly broad administrative permissions in customer PaaS accounts - Adds compatibility handling for MariaDB 11.8 secure transport defaults in infrastructure templates **Business benefits:** - Reduces the risk of unauthorized access to cloud resources and secrets - Improves security posture across customer environments - Helps maintain secure operations as infrastructure components evolve ### RDS Auditability Extensions {% include badge.html type="feature" %} We have introduced advanced activity tracking for database operations to enhance security governance and accountability across your environments. This update provides clear visibility into data modifications and structural changes within your live production systems. **Key capabilities:** - Monitors and records database operations performed in production environments - Securely retains activity logs for a rolling two-year period to satisfy standard corporate compliance and security policies. **Business benefits:** - Provides complete transparency into exactly who executed which database operation, ensuring robust compliance and clear user accountability - Enhances Security Auditing: Simplifies the detection of potential application exploits—such as SQL injections—by tracking critical service account behaviors ### Persistent Jenkins Configuration {% include badge.html type="improvement" %} We have updated our cloud automation storage model to significantly improve platform stability. This enhancement ensures that your custom adjustments are safely preserved during routine platform updates and security maintenance. **Key capabilities:** - Permanently safeguards all manually created configurations and fine-tunings across system upgrades and server restarts - Unlocks continuous, automated operating system upgrades and critical infrastructure patching to keep your system completely protected **Business benefits:** - Eliminates the risk of losing bespoke operational settings, removing the need for costly and repetitive manual reconfiguration work - Enhances your overall security posture by allowing the seamless deployment of critical patches without disrupting business continuity ### Customer authentication and session handling {% include badge.html type="improvement" %} We fixed issues affecting customer authentication and session behavior in edge cases. These changes improve reliability for API authentication and login flows. **Key capabilities:** - Prevents unintended API authentication behavior related to `spy_customer.registered = NULL` - Improves error handling for invalid JWT tokens in warehouse token requests - Avoids false-positive WAF blocking caused by `../` sequences in password hashes. **Business benefits:** - Improves trust in authentication flows - Reduces login-related support cases - Helps secure customer access scenarios more consistently **Documentation:** - [spy_customer.registered=NULL allows API auth](https://api.release.spryker.com/release-group/6618) - [Adjusted Quote data and UI fixes](https://api.release.spryker.com/release-group/6621) - [Added optional base64 encoding for gateway](https://api.release.spryker.com/release-group/6633) ### Voucher code tracking and order display accuracy in the Back Office {% include badge.html type="improvement" %} We fixed issues with orders that use multiple voucher-code discounts. The Back Office now shows the correct voucher code for each applied discount, and usage counters are updated correctly for all voucher codes used in an order. **Key capabilities:** - Displays the actual voucher code used for each discount in the Back Office order overview. - Correctly increments usage counters for all voucher codes applied to an order. - Supports orders with multiple non-exclusive voucher-based discounts more accurately. **Business benefits:** - Improves trust in discount reporting and order auditability. - Reduces manual verification effort for merchandising and support teams. - Ensures voucher campaign performance is tracked correctly. **Release:** - [Multiple voucher codes on order](https://api.release.spryker.com/release-group/6640) ### Product and catalog experience improvements {% include badge.html type="improvement" %} We improved several product-related experiences in the Back Office and storefront to make catalog management and shopping journeys more reliable. The update covers product images in Zed, product readiness visibility, replacement product rendering, and marketplace product offer handling in carts. **Key capabilities:** - Restores product concrete image visibility in the Back Office **Business benefits:** - Gives business users clearer product status information - Reduces confusion during catalog maintenance in the Back Office - Improves cart accuracy for marketplace shopping scenarios **Documentation:** - [Show Product Concrete images in Zed](https://api.release.spryker.com/release-group/6501) ### Storefront performance, search, and content management improvements {% include badge.html type="improvement" %} We improved storefront performance, search reliability, content management efficiency, and product data consistency to deliver faster customer experiences, more accurate search results, and better scalability across high-volume environments. **Key capabilities:** - Improves checkout and customer-facing page performance by reducing unnecessary backend requests and eliminating Redis bottlenecks for large datasets. - Enhances product data publishing and search indexing to keep Storage and Search synchronized with catalog changes across multi-store and multi-locale environments. - Generates search index mappings correctly for advanced analyzer and multi-field configurations. - Optimizes CMS page version history loading for better Back Office performance when managing long-lived content. - Preserves locale selection across storefront, configurator, agent emulation, and authentication flows for a more consistent user experience. **Business benefits:** - Delivers faster storefront and checkout experiences, even at scale. - Improves search accuracy and product data consistency across channels. - Enhances Back Office productivity for content managers. - Reduces backend load and improves platform scalability. - Provides a more consistent localized shopping experience for customers and support agents. **Documentation and Releases:** - [Cart page and checkout for large carts](/docs/dg/dev/guidelines/performance-guidelines/keeping-dependencies-updated#cart-page-and-checkout-for-large-carts-100-items) - [Adjusted reading shipment type uuids on Checkout](https://api.release.spryker.com/release-group/5736) - [Added child fields to index map](https://api.release.spryker.com/release-group/6616) - [CMS page versions query for the form loads too much data](https://api.release.spryker.com/release-group/6630) - [Remediate error in spryker/category >= 5.23.0](https://api.release.spryker.com/release-group/6452) - [Remove Concrete Product on deactivation](https://api.release.spryker.com/release-group/6500) - [Remove product concrete from the search index](https://api.release.spryker.com/release-group/6574) - [Locale selection preserved when navigating in the Storefront](https://api.release.spryker.com/release-group/6521) - [Performance improvements to the checkout](https://api.release.spryker.com/release-group/6479)

Process documentation guidelines

Wed, 15 Jul 2026 10:53:13 +0000

This document provides guideline templates for development teams striving for high-quality software. These templates are flexible and serve as a starting point, so make sure to adjust them to your project's requirements. Defining and following these guidelines may be necessary to fulfill project Service Level Agreements (SLAs), with each guideline explicitly outlining the responsible team. Alignment with all involved teams is essential for ensuring a functioning concept. The process documentation guidelines enhance the communication between teams over all processes and ensure that they can operate and deploy their applications the best possible way. ## Deployment guidelines The following guidelines apply to the deployment of each release candidate. ### Environment variable assertion In large teams, effective communication and issue management can be challenging. As a result, some environment variables or their expected values may not be properly set in the production environment. To minimize the risk of critical errors, we recommend running a final validation on the production environment to verify that the expected setup changes match the actual state. To run a proper validation with the understanding of the scope of these changes, make sure to provide a list of the requested changes as part of the deployment standard service request for the operations team. This final validation step ensures that the production environment is correctly configured and minimizes the risk of errors. ### Special manual steps If there are manual one-time steps that aren't automated on the application side via the deployment pipeline processes, the uniformed instructions to these exclusive requests need to be handed over to the operations team in the deployment standard service request. This also includes any dependencies that may appear between the deployment elements. For example, one component needs to be released before another; or a special timing is needed. ### Infrastructure changes Changes to the platform infrastructure and application infrastructure are carefully evaluated because mistakes in this area can cause critical problems. To reduce risks, when submitting a deployment standard service request, make sure to carefully document the intention behind each impact on infrastructure. ### Expected behavior In special cases, like technical debts, functional debts, or accepted risks, a release can lead to release specific, temporary, expected critical or warning states that doesn't have to be handled or mitigated by the operations team. To decrease unnecessary fire-fighting on both sides, list and explain these scenarios when submitting a deployment standard service request. ### Example for deployment standard service request **Title**: Deployment of version 1.2.3 to production **Description**:
This request is for the deployment of version 1.2.3 of the MyProject application to the production environment. **Requested Changes**: - Deployment of version 1.2.3 of the MyProject application - Update of the following environment variables: - Expected environment variable name: `DATABASE_URL`
Expected value: `postgresql://user:password@localhost:5432/mydatabase` - Expected environment variable name: `API_KEY`
Expected value: `abcd1234` - Expected environment variable name: `DEBUG`
Expected value: `false` - Special manual steps: - **Step 1**: Run the database migration script before starting the application. - **Step 2**: Update the DNS records for the new application version. - Infrastructure changes: - Add an additional application server to the load balancer pool. - Increase the size of the database server's disk. *Expected behavior: - There may be a temporary increase in error log entries because of a known issue with the new version that will be fixed in the next release. **Impact**:
This deployment will include updates to the application's database connection and API key, as well as changes to the infrastructure. There is a low risk of downtime during the deployment. **Rollback Plan**:
In the event of an issue during the deployment, we will roll back to the previous version of the application and revert any infrastructure changes. **Testing**:
This release has been thoroughly tested in the staging environment. A final validation on the production environment to verify that the expected setup changes match the actual state will be performed before the deployment. **Approvals**: - Lead developer: approved - QA team: approved - Operations team: approved ## Operational guidelines The following guidelines apply to operating applications or for special failure scenarios that may as well occur during deployment or rollback. Given the size and complexity of a large applications, which delivers many features with each release, unexpected errors can have multiple potential resolutions. To ensure that the most effective resolution is chosen with minimal disruption to the functionality of a successfully deployed release, implement the following operation guidelines. ### Main workflows To understand the main and critical workflows in the application, operational guidelines should outline the normal behavior of important features and workflows at the logical, component, and infrastructure levels. This forms a general overview of the logic, components, and infrastructure. This overview is necessary for making informed operational decisions and building project-specific operational dashboards, for example—to to identify and highlight project-specific bottlenecks. Also, it's needed for analyzing, answering, and resolving requests. ### Risks, early warnings, and counter actions Building a large application is usually coupled with massive application-level logging. In some cases, a critical system issue can be prevented or minimized with timely warning signals. By using regular signals, like logs and metrics, from identified business or technical bottlenecks or risks, the operations team can improve the application's stability. We recommend maintaining a list of such signals and risks in the operational guidelines. This includes recommended actions to take in order to deliver the best mitigation strategy. For more information on these guidelines, see [Operatable feature guidelines](/docs/dg/dev/architecture/non-functional-requirement-templates/operatable-feature-guidelines.html). ### Silent undesired scenario Although monitoring systems are used to detect unwanted states, some business functionality may be within acceptable metrics but not desirable under certain conditions. For example, the minimum daily browsing customer count is 10, but 11 customers during Black Friday is not considered normal. To monitor such cases, these scenarios need to be documented for the operations team. ### User guide To minimize the impact of resolution efforts and optimize the process, make sure to provide the operations team with the necessary business context. For example, resolving a small number of errors through the Back Office may be more optimal than rolling back an entire release. ### Entity size expectations The number of entities plays an important role in determining how an application will function in a production environment. To mitigate risks in this area, performance, scaling, manual tests, and reviews can be applied. However, the identified and estimated number of entities for the project can serve as a warning to pay extra attention to these entities in order to further reduce risks. For example, a marketing campaign bringing 10,000 active users to the homepage at 17:08 on Friday. ### Remote service catalog To properly handle and monitor the cooperation between local and remote or third-party services, provide the operations team with a detailed communication protocol. Make sure to additionally include the expected outages and major impacts. This way, the operations team can ignore expected outages and actively focus on known risks. For example, a payment provider connected to the project needs to be monitored to ensure its availability. The following communication protocol is used: - The local service sends an HTTP GET request to the remote service's API endpoint, along with any necessary headers and query parameters. - The remote service responds with an HTTP status code and a JSON payload containing the requested data. - The local service processes the data and displays it to the user or performs any necessary actions.

Process documentation guidelines

Wed, 15 Jul 2026 10:53:13 +0000

This document provides guideline templates for development teams striving for high-quality software. These templates are flexible and serve as a starting point, so make sure to adjust them to your project's requirements. Defining and following these guidelines may be necessary to fulfill project Service Level Agreements (SLAs), with each guideline explicitly outlining the responsible team. Alignment with all involved teams is essential for ensuring a functioning concept. The process documentation guidelines enhance the communication between teams over all processes and ensure that they can operate and deploy their applications the best possible way. ## Deployment guidelines The following guidelines apply to the deployment of each release candidate. ### Environment variable assertion In large teams, effective communication and issue management can be challenging. As a result, some environment variables or their expected values may not be properly set in the production environment. To minimize the risk of critical errors, we recommend running a final validation on the production environment to verify that the expected setup changes match the actual state. To run a proper validation with the understanding of the scope of these changes, make sure to provide a list of the requested changes as part of the deployment standard service request for the operations team. This final validation step ensures that the production environment is correctly configured and minimizes the risk of errors. ### Special manual steps If there are manual one-time steps that aren't automated on the application side via the deployment pipeline processes, the uniformed instructions to these exclusive requests need to be handed over to the operations team in the deployment standard service request. This also includes any dependencies that may appear between the deployment elements. For example, one component needs to be released before another; or a special timing is needed. ### Infrastructure changes Changes to the platform infrastructure and application infrastructure are carefully evaluated because mistakes in this area can cause critical problems. To reduce risks, when submitting a deployment standard service request, make sure to carefully document the intention behind each impact on infrastructure. ### Expected behavior In special cases, like technical debts, functional debts, or accepted risks, a release can lead to release specific, temporary, expected critical or warning states that doesn't have to be handled or mitigated by the operations team. To decrease unnecessary fire-fighting on both sides, list and explain these scenarios when submitting a deployment standard service request. ### Example for deployment standard service request **Title**: Deployment of version 1.2.3 to production **Description**:
This request is for the deployment of version 1.2.3 of the MyProject application to the production environment. **Requested Changes**: - Deployment of version 1.2.3 of the MyProject application - Update of the following environment variables: - Expected environment variable name: `DATABASE_URL`
Expected value: `postgresql://user:password@localhost:5432/mydatabase` - Expected environment variable name: `API_KEY`
Expected value: `abcd1234` - Expected environment variable name: `DEBUG`
Expected value: `false` - Special manual steps: - **Step 1**: Run the database migration script before starting the application. - **Step 2**: Update the DNS records for the new application version. - Infrastructure changes: - Add an additional application server to the load balancer pool. - Increase the size of the database server's disk. *Expected behavior: - There may be a temporary increase in error log entries because of a known issue with the new version that will be fixed in the next release. **Impact**:
This deployment will include updates to the application's database connection and API key, as well as changes to the infrastructure. There is a low risk of downtime during the deployment. **Rollback Plan**:
In the event of an issue during the deployment, we will roll back to the previous version of the application and revert any infrastructure changes. **Testing**:
This release has been thoroughly tested in the staging environment. A final validation on the production environment to verify that the expected setup changes match the actual state will be performed before the deployment. **Approvals**: - Lead developer: approved - QA team: approved - Operations team: approved ## Operational guidelines The following guidelines apply to operating applications or for special failure scenarios that may as well occur during deployment or rollback. Given the size and complexity of a large applications, which delivers many features with each release, unexpected errors can have multiple potential resolutions. To ensure that the most effective resolution is chosen with minimal disruption to the functionality of a successfully deployed release, implement the following operation guidelines. ### Main workflows To understand the main and critical workflows in the application, operational guidelines should outline the normal behavior of important features and workflows at the logical, component, and infrastructure levels. This forms a general overview of the logic, components, and infrastructure. This overview is necessary for making informed operational decisions and building project-specific operational dashboards, for example—to to identify and highlight project-specific bottlenecks. Also, it's needed for analyzing, answering, and resolving requests. ### Risks, early warnings, and counter actions Building a large application is usually coupled with massive application-level logging. In some cases, a critical system issue can be prevented or minimized with timely warning signals. By using regular signals, like logs and metrics, from identified business or technical bottlenecks or risks, the operations team can improve the application's stability. We recommend maintaining a list of such signals and risks in the operational guidelines. This includes recommended actions to take in order to deliver the best mitigation strategy. For more information on these guidelines, see [Operatable feature guidelines](/docs/dg/dev/best-practices/non-functional-requirement-templates/operatable-feature-guidelines.html). ### Silent undesired scenario Although monitoring systems are used to detect unwanted states, some business functionality may be within acceptable metrics but not desirable under certain conditions. For example, the minimum daily browsing customer count is 10, but 11 customers during Black Friday is not considered normal. To monitor such cases, these scenarios need to be documented for the operations team. ### User guide To minimize the impact of resolution efforts and optimize the process, make sure to provide the operations team with the necessary business context. For example, resolving a small number of errors through the Back Office may be more optimal than rolling back an entire release. ### Entity size expectations The number of entities plays an important role in determining how an application will function in a production environment. To mitigate risks in this area, performance, scaling, manual tests, and reviews can be applied. However, the identified and estimated number of entities for the project can serve as a warning to pay extra attention to these entities in order to further reduce risks. For example, a marketing campaign bringing 10,000 active users to the homepage at 17:08 on Friday. ### Remote service catalog To properly handle and monitor the cooperation between local and remote or third-party services, provide the operations team with a detailed communication protocol. Make sure to additionally include the expected outages and major impacts. This way, the operations team can ignore expected outages and actively focus on known risks. For example, a payment provider connected to the project needs to be monitored to ensure its availability. The following communication protocol is used: - The local service sends an HTTP GET request to the remote service's API endpoint, along with any necessary headers and query parameters. - The remote service responds with an HTTP status code and a JSON payload containing the requested data. - The local service processes the data and displays it to the user or performs any necessary actions.

Spryker Documentation

Getting started with cloud administration

Connecting to AWS Console and CLI with an IAM user

Prerequisites

Step 1: Sign in to the AWS Management Console

Step 2: Generate access keys

Step 3: Configure static credentials in your terminal

Step 4: Find your MFA device ARN

Step 5: Generate temporary session credentials

Next steps

Security

Environments overview

Basic concept

Non-production environments (NON-PROD)

Developer environment (DEV)

Staging (STAGE)

Production-like (PROD-LIKE)

Production (PROD)

Next step

Connecting to AWS CLI with an SSO user

Prerequisites

Step 1: Configure SAML2AWS

Step 2: Log in with SAML2AWS

Step 3: Use the AWS CLI

Supported browser types

OS and browser combinations

Troubleshooting

Next steps

Access

Release notes 202604.0

Release notes 202606.0

Process documentation guidelines

Process documentation guidelines