Own the journey from a local endpoint to AWS.
A web application running locally leaves an important part of the work unfinished. Its dependencies, runtime, server configuration, and process management still need to make sense elsewhere. This project was built to close the gap between understanding deployment in theory and taking responsibility for the complete path.
The scope connected a Flask backend, Docker containerisation, and deployment to an AWS environment running Linux. It brought development and delivery into the same project, so choices made in the application could be considered alongside the environment needed to run it.
I built a modular Flask application, packaged it with Docker for a reproducible environment, and handled the cloud deployment and Linux setup. The work made deployment part of the application’s construction. It required following the system beyond the source code into the conditions under which it actually runs.
A reliable deployment connects the application, its environment, and the infrastructure. Each step answers a different question.
01 / APPLICATION Flask routes → receive and validate a request → call application logic → return a clear response The first layer of a dependable system.
Architecture explanation · No live commands are executed.
Develop the Flask application and organise its API structure into clear modules. The starting point is a backend that can be understood as application logic, with a structure that remains manageable when the surrounding deployment concerns are introduced.
Containerise the application with Docker so that its runtime and dependencies travel with a defined package. This gives the deployment a repeatable foundation and reduces the distance between the development setup and the environment that runs the application.
Deploy to the cloud environment and take responsibility for the Linux configuration and process management around it. The workflow ends with the application running beyond the local machine, connecting backend development to the practical work of operating its runtime.
The Flask backend was organised around a clean, modular API structure. This keeps application responsibilities understandable and avoids treating deployment as a reason for the backend itself to become difficult to navigate.
Docker provides the project’s packaging boundary. Defining the environment alongside the application makes reproducibility an explicit part of delivery, rather than depending on a developer remembering the state of a local machine.
Linux setup and process management were within scope. Owning those details connects an application’s behaviour to the environment supporting it and makes the final result more complete than a repository that only explains how deployment might work.
The project record describes a Flask application built, containerised, and deployed to AWS. It does not specify a business domain, a currently available public demo, a traffic level, or an uptime result. The supported outcome is practical experience across backend development, packaging, and cloud deployment.
How could a fresh environment be brought up with fewer manual steps? What would make a failed release easier to identify and reverse? Further work could examine automated delivery, recovery, and clearer operational checks, with each addition justified by the application’s actual needs.
Reliability starts below the surface.