# Prongo

> A developer-first hosting platform that deploys a multi-service monorepo as one unit: shared secrets, dependency-aware deploy order, service discovery and one prongo.yaml. Free during the beta.

## Docs

- [prongo.yaml reference](https://prongo.dev/docs/config): every config field, linking services, deploy order, migrations
- [Compared to Docker, Kubernetes, Vercel and Netlify](https://prongo.dev/docs/compare): honest comparison
- [Secrets and environment variables](https://prongo.dev/docs/secrets)
- [Security](https://prongo.dev/docs/security)
- [Pricing](https://prongo.dev/pricing)

## Articles

- [Fit your app into small memory limits (and why it matters)](https://prongo.dev/blog/fit-your-app-into-small-memory-limits): Services get a fixed memory budget. Practical ways to keep a Node, PHP or Go service lean enough for a small plan without constant restarts.
- [Debug a failed deploy: a 6-step checklist](https://prongo.dev/blog/debug-a-failed-deploy-checklist): When a deploy fails, check in this order: build, pre_deploy, port, environment, dependencies and memory. Most problems are one of these six.
- [Make your Dockerfile smaller and your builds faster](https://prongo.dev/blog/make-your-dockerfile-smaller-and-faster): Four Dockerfile habits that shrink images and speed up deploys: multi-stage builds, layer order, a .dockerignore and a non-root user.
- [5 prongo.yaml tips that save you time](https://prongo.dev/blog/5-prongo-yaml-tips): Small config habits that prevent the most common deploy surprises: ordering, links, replicas, migrations and keeping secrets out of the file.
- [Heroku alternatives for monorepos and multi-service apps](https://prongo.dev/blog/heroku-alternatives-for-monorepos): Looking for a Heroku alternative? How Railway, Render, Fly.io, Coolify and Prongo handle multi-service repos, and how to choose.
- [Vercel vs Prongo for a monorepo with a backend and database](https://prongo.dev/blog/prongo-vs-vercel-for-monorepos): Vercel is excellent for frontends. Here is where a full-stack monorepo with an API, workers and a database fits better on a container-based platform.
- [How to deploy a Next.js frontend and a Node or Go API from one repo](https://prongo.dev/blog/deploy-nextjs-and-api-from-one-repo): A Next.js app calling an API with a database, deployed from a single repository: Dockerfiles, one config file, generated URLs and the right order.
- [Docker Compose vs Kubernetes vs a PaaS: what a small team should use](https://prongo.dev/blog/docker-compose-vs-kubernetes-vs-paas): Compose is simple but single-host, Kubernetes is powerful but heavy, a PaaS removes the ops. A practical way to choose for a small team.
- [How to run database migrations safely on every deploy](https://prongo.dev/blog/run-database-migrations-on-every-deploy): Run migrations and seeds as a pre-deploy step so a failed migration blocks the release instead of breaking production. Includes idempotent seed patterns.
- [How to share environment variables and secrets between services in a monorepo](https://prongo.dev/blog/share-environment-variables-between-services-in-a-monorepo): Stop copy-pasting credentials per service. Separate plain config from secrets, generate service URLs, and set each secret once.
- [How to deploy a monorepo with multiple services (frontend, API and database)](https://prongo.dev/blog/how-to-deploy-a-monorepo-with-multiple-services): Deploy a monorepo as one connected unit: describe each service once, link them with generated URLs, and let dependencies decide the deploy order.