In the dynamic landscape of SaaS companies, the relentless cycle of rebuilding tech stacks often distracts from addressing your core business challenges. Ideally, your focus should center on solving the unique problems your startup encounters. However, early-stage startups frequently invest substantial resources in infrastructure engineers, leading to unnecessary expenses.
Here, our mission is to optimize your costs, reducing them to below $15k/year while guaranteeing a 99% Service Level Agreement (SLA). We aim to standardize your technology stack, enabling the rapid reconstruction of infrastructure in a matter of days, not months.
My motivation stems from the hands-on experience of building the infrastructure for multiple saas comapny from scratch. The process revealed the repetitive nature inherent in many SaaS companies, where 80% of the infrastructure is commonly shared, leaving only 20% for unique customizations.
Understanding the difficulty of constructing a universal layer for diverse infrastructures, I observed previous attempts, such as Opta, which, despite failures, provided valuable inspiration. This realization sparked the idea to document my insights gained from the roller coaster journey.
My focus lies in a specific niche where CTOs prioritize Infrastructure as Code (IaC) for compliance, irrespective of the ongoing Terraform vs. Pulumi discussions. The emphasis is on practical solutions, leveraging Terraform if it meets the requirements. In this niche, CTOs prioritize achieving Product-Market Fit over engaging in unnecessary debates.
-
Build Once, Share with Others: Foster a collaborative environment by building infrastructure components once and sharing them with others for increased efficiency.
-
Decentralized Infrastructure Ownership: Encourage each service to own its custom infrastructure components, such as databases, message queues, and email services.
- CICD: Buildkite + GitHub + Buildkit
- Cloud Providers: AWS/GCP
- Version Control: GitHub/GitLab
- Infrastructure as Code (IaC): Terraform
- Monorepo: Turbo + Task
- Development Environment: Pixi.sh + Dev Container
- Secrets Management: AWS/GCP Secret Manager
- Container Orchestration: Kubernetes (GKE + EKS)
- Programming Languages: Go + NodeJs + Python (No Restrication)
- Database Support: No Restrication
- Communication Protocols: GRPC (buf + connectrpc) + REST
- Containerization: Docker
- Serverless Deployment: Vercel
- Observability: Grafana (OnCall + Monitoring + Observability + Tracing)
No, it's in a very early stage, and we are actively seeking partners to help build it collaboratively through open source.
Currently, we're exclusively working with AWS customers. We welcome discussions about your requirements; please schedule a call.
Enjoy a $15k/year infrastructure engineer cost with 99% uptime and a developer experience that engineers desire, backed by a community-driven scaling approach.
Absolutely! You can choose any language for your development; we don't impose any restrictions. While we've standardized a few stacks for the community, these decisions are well-thought-out and based on startup growth. Feel free to evolve your engineering stack in the future and replace them as per your specific needs.
- Buildkite over other CICD provider (TBD)
- Terraform over Pulumi (TBD)
- Why Grafana (TBD)
- Why Vercel not k8s deployment (TBD)
- Why GRPC over REST, connectrpc (TBD)
A Monorepo structure simplifies versioning, dependency management, and cross-service collaboration, promoting streamlined CI/CD pipelines, code reusability, and unified testing.
Feeling apprehensive about adopting a Monorepo? It's completely understandable. That's precisely why our existence revolves around providing the necessary tools to make running a successful Monorepo more accessible and manageable. We're here to alleviate the fears and empower you on your journey towards a streamlined development process.
Yes, our IaC architecture incorporates learnings from Opta. While Opta support is not provided, we've removed the Opta wrapper from the modules and independently maintain all modules. This IaC architecture is compliance-ready, ensuring no issues in SOC2 compliance.
Yes, at any point, involve your infrastructure engineers for CICD and IaC migration if necessary, especially as complexities arise with your growth. The entire idea here is to offer you a smooth exit path, unlike PAAS. It's 100% better then hacking around serverless funtions.
No, it's on our roadmap. We plan to address this once the project reaches a mature stage(v1.0.0)
Absolutely!, we are creating this for a community of CTOs who are tired of reinventing the wheel. With our solution, a CTO can establish their entire infrastructure within days without the need to worry about the nitty-gritty details. Once the foundation is set, you can focus on implementing unique ideas and enhance the existing stack module by module.
Certainly! Explore all the available modules here. If you can't find the module you need, feel free to create your own implementation.
Absolutely! Yes, we exclusively offer stateless automation that can be monitored through CICD, Here you need to build application for state managment
No, absolutely not. We recommend using Vercel for a full-stack solution. This tool is better suited for scenarios where your infrastructure evolves from a single app to multiple microservices.
We offer support for multiple ways to expose your app, and we are open to discussing additional possibilities. In the current setup, you can expose ingress in two ways:
- Each tenant has a unique endpoint, such as
tenant_name.us-east-2.xyz.com, consolidating the exposure of individual services. - Multiple services can share an ingress endpoint, for example,
api.us-east-2.xyz.com. - Hybrid setups are also possible.
We welcome collaboration to explore and understand other potential solutions.
At the moment, the open-source model is complimentary for startups, fostering community collaboration and knowledge sharing. For startups seeking personalized support, we provide a flexible plan that includes:
- Setup for 2 environments in 1 region wihtin 10 days
- Deployment capacity for up to 10 services
- Comprehensive features like Observability, CICD, IaC, Development Environment, and Secrets Management
- Swift deployment capabilities, enabling your developers to launch new services within 30 minutes.
Choosing to sponsor this project will prioritize your issues.
- VSCode
- Docker
- Pixi
brew install pixi - Task
brew install go-task - arkade
curl -sLS https://get.arkade.dev | sudo sh - buf
brew install bufbuild/buf/buf
To get started with this boilerplate, follow these steps:
- Clone the repository:
git clone https://github.com/yindia/saas.git - Navigate to the project directory:
cd saas - Install and get the shell by running
pixi install && pixi shell - Install cookiecutter
pip install cookiecutter - You are ready to create your first environment
An environment serves as the foundational infrastructure encompassing VPC architecture, DNS configuration, Kubernetes cluster, and Kubernetes base setup (Linkerd + Nginx + Cluster Autoscaler). To kickstart a new environment, follow these steps:
- Ensure you have an AWS account and set up AWS CLI credentials.
- Generate your initial environment by executing
task add:environment. This command prompts you with questions such as name, region, AWS account ID, etc. - The generated code resides in
infrastructure/environment/aws/{{ENV_NAME}}/{{REGION}}. - Run Terraform commands for testing and deployment.
To generate a new service, follow these steps:
- Generate your initial service by executing
task add:service. This command prompts you with questions such as name, region, AWS account ID, etc. - The generated Go code resides here
services/{{SERVICE_NAME}}, and infrastructure code is located atservices/{{SERVICE_NAME}}/infrastructurealong with a Helm chart. - Add custom Terraform configuration at
services/{{SERVICE_NAME}}/infrastructure, for example, RDS inrds.tf:
module "saas_aws_postgres" {
source = "yindia/saas/opta"
version = "1.0.0"
# insert required variables here
}
Refer to the module docs
- Please also add inputs in
input.tf, if service need any secret - Run Terraform and Helm commands for testing and deployment.
- We generate a standard helm template for each service
For complete usages, please dive into the docs.
Head over to the discussions to share your ideas.
We welcome contributions! If you have ideas for improvements or find any issues, feel free to open an issue or submit a pull request.
Thank you for considering our boilerplate for your infrastructure needs. We are eager to assist you in simplifying and optimizing your development process.
If you find this repository helpful, please consider giving it a star! ⭐️
- Checkout @mkosir's frontend-monorepo-boilerplate
- Opta