EN
Platform documentation

Getting Started

Configure your account, assemble the Magento application, and follow a change from Beta testing through a safe Production deployment.

Account preparation

Before your first deployment

Before you run your first deployment, you need to complete a few initial setup steps.

The first group of tasks is related to the security of your account. Open the Configuration page by clicking the gear icon in the top-right corner of the screen and complete the following steps:

  • Verify your phone number
  • Verify your email address
  • Set up two-factor authentication (2FA)

The next step is optional and required only if you plan to deploy private Composer or Git packages. If you do, you need to add the required keys on the Configuration page. Once you save them, we store them in a secure vault. For security reasons you will not be able to view the keys again, but they remain safely stored and available to the platform in a private network only.

Next, choose a subscription plan that suits your needs on the Configuration page.

After you complete these steps, our team will provision your dedicated AWS accounts, which usually takes 3–5 business days. Once this process is complete, you will see the "Pipeline" menu item appear in the UI.

At that point, you are ready to deploy your first Magento application. Open your Pipeline page, add the packages you want to deploy, and click "Deploy".

Subscriptions

To start using our platform, you need to subscribe to one of our plans. You can choose between three plans:

Basic

A practical starting point for small teams and startups.

Premium

Higher resource limits with an increased level of support from our team.

Enterprise

Custom setup, additional features, and 24/7 support for larger organizations.

To subscribe, simply click the "Subscribe" button on the Configuration page.

Pipeline

The Pipeline page is the main view of our platform. It shows all deployments and their statuses, test history, logs, and direct links to CloudWatch dashboards with metrics. You can roll back to a previous version in case of any issues. You can also enable automated promotion between stages to achieve full CI/CD, or disable it and manage promotions manually. Every deployment change has its own unique ID, and we use different colors to make it easy to identify the latest changes and see which stage they are currently in.

Each deployment card shows its Change ID and Build ID, current status, backward-compatibility result, start and end times, messages, and the repositories included in that build. Expand the Magento and Tests panels for environment-specific actions, or select View under Logs to inspect the output for that stage.

Packages

Our pipeline starts with adding packages. You can add packages from Composer or Git repositories, with a main package that is typically Magento 2 CE itself. You can add as many packages as you need. If you are using private packages, you must provide the necessary credentials on the Configuration page.

Use the edit button beside a repository to change its Git or Composer source, select an optional version, or designate it as the main package. A repository can also be marked as a theme. Supported theme types include Less, Sass, and PWA, allowing the deployment process to handle each frontend package appropriately.

Beta

Once your changes reach the Beta stage, you can set up automated tests for your application. You can enable API, UI, and Performance tests, and you can turn each of them on or off at any time.

The Beta deployment card also shows live deployment status, compatibility, timing, messages, repositories, Magento links and actions, and the number of configured tests. Use the gear button to configure an individual test and the play button to run it on demand.

Each test type has its own configuration options:


  • API & UI tests
    • Testsuite
    • Test filter
    • Max reruns
  • Performance tests
    • Fixture profile
    • Target cache hit ratio
    • Number of frontend users
    • Number of admin users
    • Number of loops to run all enabled tests
    • Max reruns

When you are happy with the results in Beta, you can promote your changes to Production or enable automatic promotion to make the process fully CI/CD-driven.

Promotion

Promotion moves a successfully tested change from Beta to Production. You can promote a change manually when you are ready, or enable automatic promotion so the pipeline continues after all required tests pass. Before promoting, review the deployment status and test results to make sure you are moving the intended change.

The controls between stages include Rollback and Force deploy toggles. Rollback returns traffic to the previous deployment when that action is available. Force deploy allows a deployment to continue manually; use it carefully because it can bypass the normal automated progression of the pipeline.

Production

Production deployment is the final step of the CI/CD pipeline. It can be triggered automatically after Beta tests pass. Deployments are performed with zero downtime, and you can roll back to the previous version in case of any issues. The deployment is split into two phases:

  • Services deployment: RDS, OpenSearch, ElastiCache, MQ, SES. You do not need to worry about this step—it is primarily about updating cluster configuration, enabling additional features, and upgrading to newer and more secure versions of the underlying services.
  • ECS cluster deployment: this is where the application code is replaced with zero downtime for backward-compatible changes. During this step, Admin for Magento is placed into maintenance mode, while the storefront remains fully operational.

While Production is deploying, the card displays a running status and elapsed duration. The Stop and rollback deployment action is available for supported in-progress deployments. After completion, verify the deployed repository versions, Magento status, storefront links, and logs before considering the release complete.

Application for Magento

The application block for Magento provides quick access to application-specific links, credentials, and actions for the selected environment. It includes the storefront URL for Magento, PWA URL, Admin URL for Magento, and Admin credentials. You can also use this block to apply a theme, generate Magento static files, and clear the application cache after configuration or storefront changes.

Status labels show whether Magento, static generation, and cache operations are active or in progress. Select a configured theme and click Apply to activate it. Use Re-generate after theme or frontend changes, and Clear when Magento is serving stale cached content. Some actions remain unavailable while another deployment or Magento operation is running.

How to Add a Custom Theme

Adding the package makes the theme available to the deployment, but Magento must also assign it to the intended store view before the pipeline applies it to the environment.

  1. 1

    Add the theme package

    Add the Git or Composer repository on the Pipeline page, mark it as a theme, and select the appropriate theme type.

  2. 2

    Deploy the package

    Deploy the change to the stage where you want to configure and verify the theme, then wait for the deployment to finish successfully.

  3. 3

    Open Admin for Magento

    Expand the application block for Magento for that stage and use the Admin URL and credentials to sign in to Admin for Magento.

  4. 4

    Assign the theme to the store view

    In Admin for Magento, open Content > Design > Configuration, edit the required store view, select the custom theme, and save the configuration.

  5. 5

    Apply the theme from the pipeline

    Return to the Pipeline page, choose the theme in the application block for Magento, and click Apply.

  6. 6

    Wait for completion

    Keep the page open while the theme operation runs. When its status completes successfully, open the storefront and verify the selected store view.

Repeat the Admin assignment for Magento for each store view that should use the custom theme. Test the result in Beta before promoting the change to Production.

URL Change Process for Magento

Use the URL controls for Magento when you want the environment to respond on a custom domain. Enter the new URL, confirm the change, and follow the displayed domain and certificate instructions. DNS and certificate changes can take time to become available, so wait for the process to complete before testing the new address.

  1. Save the new custom URL for Magento without including the protocol.
  2. Deploy or update the CloudFront ACM certificate created for the domain.
  3. Add the displayed ACM validation CNAME record at your DNS provider, wait for it to resolve, and run Check validation. Use the exact host and target values shown in the dialog.
  4. Deploy the CDN, then point the domain to the displayed CloudFront hostname. Use an ALIAS record for a root domain when supported, or a CNAME record for a subdomain.
  5. Change the base URL for Magento after the certificate and CDN steps report success.

Do not resolve a CloudFront hostname to its current IP addresses and create fixed A or AAAA records from those values, because CloudFront addresses can change. DNS propagation may also differ between authoritative and public resolvers, so the authoritative validation check can succeed before the record appears everywhere.

The following example shows the validation CNAME and CloudFront routing record configured in Namecheap. Other DNS providers use different labels, but the record types, hostnames, and target values follow the same process.

Logs

The Logs section helps you investigate builds, deployments, tests, and application issues. Select the relevant pipeline run or environment to view its output, then use timestamps and status messages to identify where a failure occurred. Links to the related CloudWatch logs may be available for more detailed troubleshooting.

Logs include timestamps and identifiers such as deployment IDs, which help correlate an event with its pipeline card and AWS deployment. Use Refresh to load newer output while a job is running and Copy to capture the log for searching, sharing, or attaching to a support request. When troubleshooting, begin near the first explicit error rather than the final pipeline failure message, which is often only a summary of an earlier problem.