Over the past few months, I've completed hands-on learning across Linux, Docker, Docker Compose, Git, GitHub Actions, AWS EC2, Nginx, PostgreSQL, networking fundamentals, and production-style deployments.
One of the projects I built follows this architecture:
Internet
│
▼
AWS EC2
│
Docker Compose
│
┌─────────────┐
│ Nginx │
└─────────────┘
│
▼
┌─────────────┐
│ Flask │
└─────────────┘
│
▼
┌─────────────┐
│ PostgreSQL │
└─────────────┘
The deployment pipeline is fully automated:
- Push to GitHub
- GitHub Actions runs
- SSH into EC2
- Pull latest code
- Rebuild containers
- Restart services
- Verify deployment
Everything works.
The application is publicly accessible.
Health checks are configured.
Persistent storage is configured.
Containers are rebuilt automatically.
Yet I still don't feel confident enough to say I deeply understand every engineering decision.
That realization changed how I want to learn.
Tutorials teach how.
Engineering requires understanding why.
Why should Nginx be public while Flask stays private?
Why are containers disposable?
Why are volumes persistent?
Why do health checks matter?
Why does Docker networking work the way it does?
Why does CI/CD fail in production?
These questions aren't answered by simply completing another tutorial.
What's next for Gravoxlab?
Rather than rushing through more courses, I'll spend time revisiting concepts, creating production-style labs, intentionally breaking systems, debugging failures, and documenting everything publicly.
My goal isn't to become someone who finishes tutorials.
It's to become someone who can reason through real systems.
If you're on a similar journey, I'd love to hear how you transitioned from following tutorials to confidently solving engineering problems.
Top comments (0)