Skip to content

itsMehcom/infra

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ItsMeh Cloud Infrastructure

Welcome to the infrastructure repository for the ItsMeh project! This repository uses a modern, layered Infrastructure-as-Code (IaC) approach. It centralizes our deployment architecture, reverse proxy routing, and essential application services.


📂 Repository Structure

Our infrastructure is split logically by concern to make it easy for developers to find what they need.

infrastructure/
├── deploy/           # Helper scripts to validate and deploy resources
├── environments/     # Environment-specific configuration maps (e.g., global.env, postgres.env)
├── platform/         # Foundational systems (reverse proxy, database, monitoring)
│   ├── reverse-proxy/   # NGINX reverse proxy
│   ├── postgres/        # PostgreSQL shared database platform
│   └── pgadmin/         # pgAdmin 4 database management UI
├── services/         # Application workloads (backend server, web frontend, microservices)
└── logs/             # Centralized log storage generated by running containers

🧠 The Mental Model

When navigating this repository or deciding where to place a new piece of infrastructure, use this simple mental model:

Services (/services)

"What your product needs to exist"

These are directly part of your product. Without them, your app is fundamentally broken (e.g., your Core API, PostgreSQL database, or specific microservices).

  • If this goes down, users will notice immediately.
  • Focus: Business continuity, scaling, data integrity, application code.

Platform (/platform)

"What operations need to keep it alive"

These are infrastructure support systems. Without them, your app may still run temporarily, but operations become dangerous, insecure, or unobservable (e.g., NGINX reverse proxy, PostgreSQL shared database, Grafana monitoring, back-up automation).

  • If this goes down, users might not notice entirely, but the operations team will panic.
  • Focus: Operational safety, observability, network security, automation, data platform.

🚀 Getting Started

Are you a newcomer trying to spin up or deploy this code? Follow these steps:

1. Setup Your Environment Variables

All configuration strings, secrets, and API domains are centralized in the /environments folder.

  1. Navigate to /environments/production/.
  2. Copy global.env.exampleglobal.env and fill in your domains (e.g., DOMAIN, API_DOMAIN, PLATFORM_SUBDOMAIN).
  3. Copy postgres.env.examplepostgres.env and set your database superuser password.
  4. Copy pgadmin.env.examplepgadmin.env and set your pgAdmin admin credentials.
  5. See platform/postgres/README.md for full database setup and onboarding.
  6. See platform/pgadmin/README.md for pgAdmin setup.
  7. Create backup dirs: mkdir -p platform/postgres/backups/{base,wal,logical}
  8. Generate platform services gateway credentials: htpasswd -c platform/reverse-proxy/nginx/.htpasswd ops_admin

2. Launching Services

Deployment shouldn't be a manual guessing game mapping docker commands for every container. We leverage helper scripts in the /deploy folder to automate validation and startup.

Example for deploying the production stack:

cd deploy/
./deploy-prod.sh

3. Reviewing Logs

Most platform tools and services map their log outputs to the top-level /logs directory (e.g., /logs/nginx/). This makes tailing logs across services easy without having to jump into individual docker containers.


🔒 Best Practices

  • No Secrets in Git: Never commit .env files. Always use .env.example as a template and keep the real configured keys locally on the destination machine.
  • Test Before Updating: Scripts like ./deploy-prod.sh automatically validate configuration (like nginx -t for templates) before restating runtime services—always use the scripts instead of raw commands whenever possible to catch configuration errors early!

🤝 Contributing

We welcome contributions! If you have suggestions for improving the architecture, adding new platform tools, or optimizing the reverse proxy, please feel free to:

  1. Fork this repository
  2. Create a feature branch (git checkout -b feature/amazing-improvement)
  3. Commit your changes (git commit -m 'Add amazing improvement')
  4. Push to the branch (git push origin feature/amazing-improvement)
  5. Open a Pull Request

📄 License

This project is open-source and licensed under the MIT License. You are free to use, modify, and distribute this infrastructure configuration for your own projects. See the LICENSE file for more details.

About

ItsMeh Cloud Infrastructure as Code

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages