Deploy from Git or Workspace

Use Deploy now to release a branch, tag, exact commit, or the App’s current server-side Workspace.

Read Git and Workspace deploys before choosing Workspace on an App that also has a connected repository.

Before you begin

For a Git deploy, the App must have an active repository connection. If the Deploys page shows Reconnect needed, an owner or admin must reconnect the synsmarts GitHub App installation before continuing.

For a Workspace deploy, confirm the files currently visible through the managed workspace are ready to publish. The deploy workflow captures eligible release files after dispatch, when it reaches its source-capture step. Avoid changing the Workspace until the deploy detail reaches Validating, which occurs after source capture.

Workspace capture excludes platform-defined runtime, cache, generated, media, and secret paths, plus paths matched by .deployignore. For Magento, a supplied vendor/ dependency tree is captured; the build validates it before reuse.

Don’t deploy while another App operation is still active. Wait for its terminal outcome so the new deploy has an unambiguous starting state.

Deploy the first repository revision

After connecting a repository, synsmarts returns to Deploys without starting a release.

1. Find Deploy now.
2. Keep Git selected.
3. Confirm the preselected branch. It initially uses the repository’s default branch.
4. Select Deploy.

The portal opens the new deploy’s detail page. Connecting the repository and starting the first deploy are separate customer actions.

Choose Git or Workspace

• Choose Git to release a branch, tag, or commit from the connected repository.
• Choose Workspace to release the App’s current workspace files. There is no Git reference to enter for this source.

A connected App can submit a Workspace deploy from this screen. Choosing a different source for the next deploy doesn’t change the repository connection, automatic-deploy setting, or selected Git reference.

Git and Workspace aren’t bidirectionally synchronized. After a successful Git deploy, synsmarts attempts to refresh the Workspace from the built release. The Git release remains live even if that refresh fails, so inspect the Workspace before publishing it. A Workspace deploy doesn’t commit its files back to Git, and a later Git deploy can replace code changes that exist only in the Workspace. Commit any change that must survive future Git deploys to the repository.

Code-only and proven additive Magento changes deploy with no planned interruption. Breaking or unclassifiable Magento database changes take the App into a maintenance window while the migration and cutover run. The deploy doesn’t wait for approval before entering that window, so start migration-bearing Magento releases when a short interruption is acceptable.

See How deploys move from code to traffic for the exact Git and Workspace detection rules and per-path recovery behavior.

Start the deploy

1. Open the App in the synsmarts portal.
2. Select Deploys.
3. In Deploy now, select Git or Workspace.
4. For Git, select the branch or tag. To deploy an exact commit instead, open Advanced: deploy a specific commit and enter a 7-40 character hexadecimal Git commit SHA.
5. Select Deploy.

Without an exact commit SHA, synsmarts deploys the current tip of the selected branch or tag. Redeploy resubmits the stored branch, tag, or commit. A branch or tag is resolved again, so its redeploy uses the tip current at that time. Enter a commit SHA when you need to reproduce an exact Git revision. A Workspace redeploy captures the current workspace again when the new workflow reaches its source-capture step.

If branches and tags can’t be loaded, enter the Git reference manually. Confirm the spelling before submitting; a nonexistent or inaccessible ref fails during source validation.

The App has one active environment, so Deploy now doesn’t ask you to choose an environment. The deploy applies to the App currently open in the portal.

Follow progress

After the request is accepted, the portal opens the new deploy’s detail page. The accepted request isn’t yet a successful release. Use the status and timeline until the deploy reaches Complete, Failed, Restore failed, Cancelled, or Superseded.

The timeline can include validation, migration classification, build, migration, deployment, promotion, and cleanup. It shows only stages the operation actually reached.

If the deploy fails:

1. Read the failure summary on the deploy detail page.
2. Record the failed stage and any visible error identifier.
3. Correct the reported problem before starting another deploy.
4. Contact support if the suggested action doesn’t resolve the failure.

Starting another deploy without addressing the failure usually repeats the same result and makes the useful operation harder to identify.

Verify the release

After the deploy completes, open the App’s live URL from Overview. Verify the changed path, the App’s primary customer flow, and any database behavior affected by the revision.

For a Workspace release, confirm that the live App contains the eligible Workspace changes present when source capture ran. For a Git release, confirm the history source is the branch, tag, or exact commit you intended and test the live App.

Optional: deploy automatically on push

Team owners and admins can enable Auto-deploy when I push from the repository card on the Deploys page. Select the branch or tag that should trigger a deploy, then save the setting.

Leave automatic deploys off when pushes require a separate review or release decision. The setting is off by default, including immediately after connecting a repository. Removing or suspending the GitHub App installation stops push-triggered deploys until access is restored.