As we embarked on the deployment of a Laravel application using Vapor, we encountered an unexpected deviation from the documented process. The network, which was supposed to be automatically created during the initial deployment, failed to materialize. This unforeseen challenge necessitated a manual intervention, requiring us to navigate through the Vapor UI and meticulously configure a new network, specifying both the region and network name. Then we created a fixed publicly accessible database with minimum configuration (db.t3.micro - 2VCPU 1Gib RAM...

Recently I was trying to deploy a Laravel Application using Vapor. I wanted to deploy it to a subdomain. There were many projects deployed on several subdomains of our main domain. Since I wanted to deploy using Vapor which is basically serverless, there were basically no IP Addresses or URLs to point the domain to. I went through the Vapor Documentation about the domain section, but it said nothing about how to point the subdomain. So I contacted the Laravel Vapor support about my problem. They responded that I needed to add the main Domain to Vapor and the subdomain will automatically be added and no problem will happen to my existing subdomains after doing this. After their response, I added the main domain from the Vapor UI. PS: Thanks for the great support from

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files. Consider, User A uploaded a private photo at http://www.mysite/private/photo/5 and User B uploaded a photo at http://www.mysite/private/photo/6  (you should never use incremental ID's in the URL in the first place, use some random keys. This is just an example to show the concept.) Now User B shouldn't be allowed to view the photo of User A at http://www.mysite/private/photo/5, but many develope...