Laravel Cloud CLI now understands GitLab and Bitbucket repositoriesLaravel Cloud CLI now understands GitLab and Bitbucket repositories

Your remote no longer has to be GitHub

When a project lives on GitLab or Bitbucket, a deployment CLI that assumes GitHub creates unnecessary friction. This is not only about showing the wrong provider: Laravel Cloud needs the provider as part of the repository information, and it affects links to branches and commits. Version 0.6.0 of cloud-cli adds GitLab and Bitbucket alongside the existing GitHub provider. (github.com)

The usual path is straightforward because the CLI resolves the provider from the origin remote. That keeps the normal workflow intact when the repository is already configured properly and avoids entering the same metadata twice. When the host cannot be identified, the command can ask for a provider interactively or accept --source-provider. (github.com)

Setting the provider explicitly

The option is available through cloud ship, as well as when creating or updating applications. The supported values in this release are github, gitlab, gitlab_self_hosted, and bitbucket. For automation, I would set it explicitly when the remote is non-standard or when another pipeline step creates the repository setup. (github.com)

cloud application:create \
  --repository=team/my-application \
  --source-provider=gitlab \
  --region=us-east-2 \
  -n

This uses options documented by the CLI itself: repository, source provider, region, and non-interactive mode. In a conventional repository, though, there is no need to force --source-provider if origin points to a recognized host. The useful change is that the provider is no longer an implicit GitHub-only assumption and is sent with the application data. (github.com)

A cloud ship flow that eventually stops waiting

The other important change is the final readiness check in cloud ship. In version 0.6.0, that wait is capped at 120 seconds and connection failures are handled while a domain is still resolving. Once the deadline is reached without a valid response, the command does not remain stuck forever. (github.com)

That matters in CI, where a hanging process wastes build time, blocks runners, and leaves an unclear outcome. The flow can now finish with a warning and let you decide whether to inspect logs or fail the pipeline. It does not make a deployment successful by itself, but it makes the behavior bounded and easier to automate. (github.com)

The fine print

This is not a full integration with every provider feature. For Bitbucket, the project explicitly states that the CLI does not create repositories: you must create the repository separately and add it as a remote before continuing. GitLab and Bitbucket are covered for provider detection, provider submission, and URL generation, but that does not replace the access configuration required by each repository. (github.com)

There is also an important detail in the readiness logic. A 404 is treated as a domain that is not routing to the application yet, so the CLI keeps retrying; a 401 or 403 is considered a valid response from an application that protects its root route. Server errors are not accepted as ready, while connection failures are retried until the timeout expires. (github.com)

I would not use this check as a complete health-monitoring strategy. A response from the main URL does not prove that workers, queues, a protected route, or an external dependency are healthy. Production deployment validation should still combine the CLI with targeted HTTP checks, logs, and alerting outside the publishing process.

Who should update

If every project is on GitHub and cloud ship is only used manually, this release may not look dramatic. For Laravel projects hosted on GitLab, Bitbucket, or a self-hosted GitLab instance, it removes a real mismatch in the workflow. For automated deployments, the bounded readiness wait is a practical improvement even when the application code stays exactly the same. (github.com)

Original source · Official Laravel Cloud CLI documentation