To invoke Laravel's internal scheduler, you must call the schedule:run Artisan command once every minute. In a traditional serverful hosting environment, you may achieve this using a utility such as cron.
Joe Dixon
AWS has been providing certificates from the rds-ca-2019 Certificate Authority, but these certificates are due to expire in August 2024. If you are running an RDS instance using this Certificate Authority, it must be updated to prevent any interruption in connectivity after this date.
Joe Dixon
We're thrilled to introduce zero downtime deployments to Laravel Forge, thanks to a seamless first-party integration with Envoyer. Envoyer's zero downtime deployments ensure you avoid even those brief milliseconds of downtime while the server updates your code.
James Brooks
Volt is an elegantly crafted functional API for Livewire, allowing component's PHP logic and Blade templates to coexist in the same file. Behind the scenes, the functional API is compiled to Livewire class components and linked with the template present in the same file.
Nuno Maduro
Today, we are releasing the first beta of Laravel Folio. Folio is a powerful page-based router designed to simplify routing in Laravel applications. With Laravel Folio, generating a route becomes as effortless as creating a Blade template within your application's "resources/views/pages" directory.
Nuno Maduro
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!
Joe Dixon
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.
Joe Dixon
When Vapor handles incoming HTTP requests or queued jobs, it writes debug information to your CloudWatch logs. This includes logging when your application's configuration is cached, environment variables are decrypted, FPM status, and more. Rarely, these logs can assist in debugging problems with your application, but most of the time they are simply added noise.  Beginning today, we are disabling these logs by default, removing the unnecessary noise and allowing you to focus on what's important when debugging your application. This change may also result in a reduction of your AWS bill, particularly on high-traffic applications, as this update reduces the total number of logs written to CloudWatch. Of course, occasionally, you may still wish to view Vapor's debug logs. You may opt-in to these logs from the "Logs" page of your environment in the Vapor dashboard, or by using the `--debug` option when deploying from the CLI: ```shell vapor deploy production --debug ``` This update is available beginning today, but you must upgrade to the latest versions of `vapor-core` (`v2.31.0`) and `vapor-cli` (`v1.56.0`) for the changes to take effect.  At Laravel, we strive to make the very best developer tooling out there, and we hope you agree this improvement to Vapor is another step in the right direction.
Joe Dixon
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.
Tim MacDonald
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.
Joe Dixon
Laravel is the most productive way to
build, deploy, and monitor software.
