Product

Vapor has always made it straightforward to deploy your application to a custom domain, subdomain, or even wildcard subdomain. However, it’s only been possible to utilize single-level subdomains - meaning it was possible to deploy your application to `api.example.com`, but not `v1.api.example.com` or `staging.v1.example.com`. Today, we’re thrilled to announce support for multi-level subdomains on Vapor. To take advantage of this feature, first, ensure the root domain is added as a domain to Vapor. This can be done either directly from the Vapor dashboard or by using the Vapor CLI: ```bash vapor domain example.com ``` Once the domain has been added, you must request a certificate. Wildcard certificates provided by AWS Certificate Manager can only protect single-level subdomains, so to protect a multi-level subdomain, the subdomain must be explicitly added to the certificate. When requesting a certificate from the Vapor dashboard, you may explicitly add the multi-level subdomain by either adding it as the “Domain Name” or any of the “Alternative Names”.  Alternatively, you may request the certificate from the Vapor CLI: ```bash vapor cert my.really.long.multi.level.subdomain.laravelvapor.rocks ``` When the certificate has been issued, you can add the multi-level subdomain to the domain section of your `vapor.yml` file and carry out a full deployment using the Vapor CLI. As previously discussed, wildcard certificates cannot protect multi-level subdomains, so the multi-level subdomain must be explicitly defined in the `vapor.yml` file - relying on wildcard subdomains is not possible. ```yml id: 12345 name: vapor-rocks environments: production: domain: my.really.long.multi.level.subdomain.laravelvapor.rocks build: - 'composer install --no-dev' ``` Vapor will automatically find the correct certificate to protect the multi-level subdomain and attach it to your environment, regardless of whether you use API Gateway v1, API Gateway v2, or a load balancer. That's it! Assuming you are using Vapor to manage your DNS, your application will be available via your multi-level subdomain when the deployment completes. We hope you enjoy using this new feature of Vapor and look forward to hearing any feedback you may have!

Today, we’re announcing the deprecation of a number of our native runtimes and wanted to take the opportunity to communicate what this looks like both now and moving forward.

Laravel Forge's "quick deploy" feature gives your team a seamless push-to-deploy experience. Whenever new code is pushed to your deployed branch, Forge will kick off a new deployment. This ensures that your site is always running your project's latest code. Forge will also display the commit information in the "Deployments" table, so you can keep track of what was deployed, and when. Unfortunately, projects triggering deployments via the "Deployment Trigger" URL or using a custom source control provider could not take full advantage of this feature - until now. ### Improved Quick Deploy For Custom Providers Many sites on Forge using a custom source control provider are actually using a first party supported git provider, i.e., GitHub, GitLab, or Bitbucket, as their source control host, because doing so enables a team with complex project access requirements to deploy repositories that are not contained in their Forge linked source control account. For these sites Forge will now detect the first party supported git provider and recommend setting up webhooks via the provider's native webhook functionality.  Once set up, when Forge receives a "push" webhook from GitHub, GitLab, or Bitbucket, the commit information will now be detected and populated in the deployments table. The `FORGE_DEPLOY_COMMIT`, `FORGE_DEPLOY_AUTHOR`, and `FORGE_DEPLOY_MESSAGE` environment variables will also be populated for use in the site's deploy script.  ### Manually Providing Commit Details For sites using a different source control provider altogether or triggering deploys from CI, Forge has no way of knowing the commit hash, author, branch, or message. That is why we have rolled out the ability to pass this information through to Forge via query parameters in the Deployment Trigger URL. Forge has introduced 4 reserved query parameters you may use to pass this information through: - `forge_deploy_branch`: The branch that contains the commit. Forge will only trigger a deployment if the branch matches the site's currently deployed branch. - `forge_deploy_commit`: The hash of the commit. This will be visible in the "Deployments" table and be available as the `FORGE_DEPLOY_COMMIT` environment variable in your deploy script. - `forge_deploy_author`: The author of the commit. This will be visible in the "Deployments" table and be available as the `FORGE_DEPLOY_AUTHOR` environment variable in your deploy script. - `forge_deploy_message`: The commit message. This will be available as the `FORGE_DEPLOY_MESSAGE` environment variable in your deploy script. For example, in your CI script you could pass commit message "WIP" through to Forge when calling the deployment trigger URL: ``` COMMIT_MESSAGE="WIP" curl "https://forge.laravel.com/servers/676709/sites/1968614/deploy/http?token=xxxx&forge_deploy_message=$COMMIT_MESSAGE" ``` We hope these improvements will make working with custom source control providers and deploying via CI a nicer experience. If you have any further suggestions on ways we can improve custom integrations with Forge, we'd love to hear them.

Today we're super pumped to announce Arm powered runtimes on Vapor. Powered by AWS Graviton 2 processors, applications will see up to 20% better performance at a 20% cost reduction.

Today, we're excited to announce that by combining the power of CloudWatch with the sleek and intuitive Vapor UI, we're making application logs available directly in the Vapor dashboard.

Today, we're excited to announce it's now possible to set the maximum concurrency of individual Vapor queues. This new feature will allow you to ensure that not one of your queues can consume all of the available resources.