Amazon Web Services

AWS is where the application runs in production. A Laravel API, the workers that process queues, the MySQL database, and the files the product stores need a hosted environment. We use AWS for that origin. Cloudflare provides the edge in front of it. The two are documented separately because they do different jobs.

The exact services depend on the project. A small API and a multi-tenant platform do not require the same architecture, and we do not apply a fixed service list to every engagement.

Start a conversation about hosting an application, or read Project initiation.

At a glance

When we use it

• Running the PHP application and its queue workers in an environment that can be restarted, scaled, and monitored
• A managed MySQL database, so the system of record is backed up and is not stored on the application server’s disk
• Object storage for imports, exports, images, and documents
• A small standalone endpoint, when a full application is not the right shape for a single job

We do not create a new multi-account landing zone unless the organisation already has one and the project must fit it.

What we rely on

The set of services is kept to what the release requires.

• Compute for the Laravel application and its workers
• A managed relational database, described on the MySQL page
• Object storage for files that should not be stored in the database
• Identity and secrets handling, so credentials are not stored in the repository
• Logs and failure alerts for jobs that run without a person watching the request

A service is added because the architecture needs it. A possible future requirement is not, on its own, a reason to run it now.

Why it fits the work

• An environment the first release can run in. Environments exist before launch, so deployment is a repeatable step.
• Capacity for workers as well as web requests. Imports, synchronisation, and mail are often the larger load. They can scale on their own schedule, separately from page traffic.
• Backups and isolation as a managed service. We still decide what is backed up and who can reach it. We do not build that foundation ourselves.
• A cost that can be explained. Fewer services means a smaller invoice and a smaller system to hand over. Unused infrastructure is a cost, not evidence of a more serious design.

How we build with it

The engagement follows Project initiation. Hosting is part of the architecture.

• Architecture. What runs, where the data lives, and what an outage means for the first release. Existing hosting constraints are useful input. They are often already fixed.
• Development. Environments that are close enough to production for queues, storage, and mail to behave as they will in production. Configuration comes from the environment, not from a file copied between machines.
• Hardening. Least privilege on credentials, private data stores, and no administration interfaces left open because a security group was not reviewed. TLS at the edge is provided by Cloudflare.
• Release and support. Deployments, backups, and review of failed jobs after launch. Ongoing development includes the infrastructure the application uses. It does not include a separate retainer for unused resources.

How it sits in the stack

AWS is the origin for Laravel and MySQL. Nuxt may be deployed alongside it, or as static and server output behind Cloudflare, depending on the application. Flutter does not run on AWS. It calls the API that does.

Cloudflare is in front, for DNS, TLS, and caching. We do not place another content network behind it unless there is a specific requirement.

In practice

The Laravel applications we operate need an origin that can host the PHP process, the workers, and MySQL. AWS is that origin. dCommerce is the reference for the application shape. The services in the account are those named in the architecture for that release. They are not a commitment to every AWS product.

Questions

Do you only host on AWS?

AWS is the hosting we standardise on, which is why it is part of the stack. If you already run elsewhere, and that hosting must stay, please say so at the start. Fitting an existing host is a scoping question. We do not assume that every project begins with an empty account.

Will the application be tied to AWS?

It will use the services it is deployed on. The application itself remains Laravel, MySQL, and ordinary files. Moving later is real work, mostly at the edges: queues, storage, and secrets. We do not place business rules inside a proprietary workflow service in order to save implementation time.

Who owns the account?

The account is yours, unless we have agreed to operate it for you. Credentials, billing, and the ability to leave are part of the handover. A production system that only a vendor can access has not been handed over.

Next step

Hosting is decided with the architecture, before production code depends on a local machine. Start a conversation.

Related: Cloudflare, Laravel, MySQL, Technology.