From “It Works on My Machine” to “It Works in the Cloud”
A practical beginner’s perspective on turning a locally working application into a more predictable, secure, and monitorable cloud deployment using AWS concepts.
From “It Works on My Machine” to “It Works in the Cloud”
There is one sentence almost every developer hears sooner or later:
“But it works on my machine.”
The application runs perfectly on a laptop. The API responds, the database connects, and everything looks fine.
Then it is deployed somewhere else—and suddenly something breaks.
Maybe an environment variable is missing.
Maybe a required dependency is unavailable.
Maybe a port is different.
Maybe the application cannot reach the database.
Maybe a required dependency is unavailable.
Maybe a port is different.
Maybe the application cannot reach the database.
This made me realize something important while learning cloud computing:
Deployment is not simply moving code to a server. It is making the environment predictable.
AWS helped me understand this idea more clearly.
Why Local Development Can Be Misleading
When an application runs locally, the developer controls almost everything.
We know:
- Which programming language version is installed
- Where the application files are located
- Which database is running
- Which ports are being used
- Which environment variables exist
- Which dependencies have already been installed
A cloud environment does not automatically know these assumptions.
An application needs its requirements to be clearly defined.
For example, a project may depend on:
- A specific runtime
- Environment variables
- Network connectivity
- Database access
- Storage
- Authentication
- Logging
- Monitoring
If these requirements are not clearly understood, deployment becomes a guessing game.
That is why I started looking at deployment as a repeatable process, rather than something I do only after finishing the code.
A Simple Way I Think About Cloud Deployment
Before deploying an application, I try to answer five questions.
1. What exactly am I deploying?
Is it a:
- Web application?
- REST API?
- Static website?
- Background service?
- Data-processing application?
Understanding the application comes first.
There is no single AWS service that is automatically correct for every project.
2. Where should the application run?
AWS provides different options for running applications.
Depending on the project, developers can work with services such as:
- Amazon EC2
- AWS Lambda
- Amazon ECS
- AWS Elastic Beanstalk
The important thing is not choosing the service with the most features.
It is choosing an option that matches the application's requirements and the team's ability to manage it.
For a beginner, starting with a simple architecture can make the learning process much easier.
3. Where does the data live?
Applications rarely consist only of code.
They may need:
- Databases
- Images
- Documents
- User uploads
- Logs
- Temporary files
For example, Amazon S3 can be used for object storage, while Amazon RDS provides managed relational database options.
Thinking about storage separately from application logic helps make the architecture easier to understand.
4. How is configuration handled?
This is one of the easiest things to overlook.
A local project might contain configuration such as:
1
2
3
PORT=5000
DATABASE_URL=localhost
API_KEY=example-secret
But a cloud environment is not the developer's laptop.
localhost may point to a completely different place depending on where the application is running.Configuration should therefore be treated separately from application code.
Most importantly, sensitive credentials should not be casually placed inside source code or committed to a public Git repository.
5. How will I know when something goes wrong?
An application being successfully deployed does not mean the job is finished.
A better question is:
“If this application fails tomorrow, how will I find out why?”
This is where logging and monitoring become important.
Amazon CloudWatch can help with monitoring and collecting logs, making it easier to investigate application behavior.
Instead of simply knowing:
“Something is broken.”
we can work toward knowing:
“The application generated an error at a specific time, and the logs help identify what happened.”
That difference can save a lot of debugging time.
A Small Example
Imagine I build a simple student task-management application.
Locally, I might think about it like this:
1
2
3
4
5
6
7
8
9
10
User
|
v
Frontend
|
v
Backend API
|
v
Database
When moving toward AWS, I need to think about each part separately:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
AWS Environment
User
|
v
Application
|
+---- Compute
|
+---- Database
|
+---- Storage
|
+---- Monitoring
|
+---- Security
The architecture does not need to become complicated just because it is running in the cloud.
The goal is to understand why each component exists.
My “Works on My Machine” Checklist
Before deployment, I find this checklist useful.
Application
- Is the required runtime version documented?
- Are dependencies clearly defined?
- Can the application start without manual changes?
Configuration
- Are environment variables documented?
- Are secrets kept outside source code?
- Are development and production configurations separated?
Database
- Does the application know where the database is?
- Are credentials managed securely?
- Can the application environment communicate with the database?
Networking
- Which ports are required?
- Which components need to communicate?
- Is unnecessary network access blocked?
Monitoring
- Where will application logs be available?
- How will errors be investigated?
- How will I know if the application stops working?
Recovery
- What happens if the application crashes?
- Can it be restarted easily?
- Is important data protected?
These questions are simple, but they can prevent many avoidable deployment problems.
Security Should Start Early
Cloud security should not be something added after deployment.
Some basic habits are worth developing from the beginning:
- Never publish secret credentials in source code.
- Give users and resources only the permissions they need.
- Avoid exposing unnecessary ports.
- Keep sensitive configuration outside public repositories.
- Review permissions regularly.
- Monitor important activity.
AWS Identity and Access Management (IAM) is especially important because it controls access to AWS resources.
One principle I want to keep in mind is:
Give the minimum permissions required to perform the job.
This is the principle of least privilege.
Start Small Instead of Building Everything at Once
One mistake beginners can make is trying to build a huge cloud architecture immediately.
More services do not automatically mean a better architecture.
A small project may only need a few components.
A better learning approach is:
Start simple → understand → monitor → secure → improve.
This makes AWS easier to learn because every service has a clear purpose.
Instead of memorizing dozens of AWS services, I can focus on understanding the problem each service solves.
The Biggest Mindset Change
The biggest lesson for me is not learning another AWS service.
It is learning to ask better questions.
Instead of asking:
“How do I deploy this application?”
I can ask:
“What does this application need to run reliably?”
That question changes the way I think about cloud architecture.
It makes me consider:
- Compute
- Storage
- Networking
- Security
- Configuration
- Monitoring
- Reliability
- Cost
Cloud computing becomes much easier to understand when these concepts are connected to an actual application.
My Practical Deployment Flow
For future projects, I want to follow a simple process:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Build
↓
Document dependencies
↓
Separate configuration
↓
Choose suitable AWS services
↓
Deploy a small version
↓
Check logs and monitoring
↓
Review security
↓
Improve gradually
This feels more practical than trying to design a perfect architecture on day one.
Final Thoughts
AWS is not just about running an application on a remote computer.
For me, the more valuable lesson is learning how to think about software as a complete system.
Good code is important, but reliable software also needs a predictable environment, secure configuration, suitable infrastructure, useful logs, and a plan for handling failures.
So the next time an application says:
“It works on my machine.”
I want to ask a different question:
“Can we make it work reliably wherever we deploy it?”
That is the mindset I want to continue developing as I learn cloud computing and build more real-world projects.
Build locally. Think globally. Deploy intentionally.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article