Skip to main content
Most apps need more than their own code: a database, a cache, object storage, a payment provider. In Monk these come from packages, and they sit in the same MANIFEST and templates as your own services. Monk deploys them with your app and wires the connections between them.

​
Packages and entities

A package is a reusable definition that your templates can load. There are two kinds of thing a package can provide.
  • Containerized services (templates). Software that runs in containers on your cluster, such as PostgreSQL, Redis, Kafka, Nginx or Prometheus with Grafana. The package carries the container setup, services, volumes and checks.
  • Entities. Definitions that manage a resource through a provider’s API rather than running it in a container: an AWS RDS database, an S3 bucket, a GCP Cloud SQL instance, a Neon project, a Stripe webhook endpoint, a Cloudflare DNS record. The orchestrator creates, updates and deletes the resource with your credentials for that provider.
When your coding agent configures a project, it searches the available packages before writing a service by hand. It then reads the package’s services, variables, connections and generated secrets. Your own services connect to a package through Monk connections, not hard-coded hostnames, and you override settings with inherits. The full list is on monk.io/integrations.

​
Self-hosted or managed

For many services you can choose where they run: The plan you approve shows which option a deploy uses. Ask for the other one if you’d rather have it.

​
Databases and your data

A stateful service needs a volume, and your coding agent declares one for every database, queue or store it adds. Some points to know:
  • Monk doesn’t move data for you. When you switch a database from self-hosted to managed, or from one provider to another, Monk points the app at the new database. The rows stay where they were. Copying data is a separate step that you plan and run.
  • A new environment starts empty. Preview environments and new deployments of an existing app don’t copy production data.
  • Backups depend on the package. Some packages declare custom actions such as creating or restoring a snapshot. Monk can run them, and each run asks for your approval. Where no such action exists, use the database’s own tools or the provider’s backups. See Backup and restore.
  • Deleting is destructive. Purging a workload removes its stored state. Monk asks for approval first.

​
Third-party APIs

Some packages manage your accounts with outside services. Today they include:
  • Payments: Stripe (products, prices, webhook endpoints)
  • Auth: Auth0, AWS Cognito, Clerk, WorkOS
  • Databases and storage: Neon, Supabase, MongoDB Atlas, Redis Cloud
  • Hosting and edge: Netlify, Vercel, Cloudflare (DNS, Pages, Workers, tunnels)
  • Email: AWS SES
Monk needs an API key or token for each service you use. It asks for it through a credential form in the local dashboard, never in chat. See Security.

​
Secrets that services need

Packages generate their own secrets, such as database passwords, and pass them to the services that connect to them. You don’t type those. Secrets that only you can provide, such as a Stripe key, are listed in the MANIFEST and requested through a form when they are missing. See Secrets and config.

Add a database

Choosing and adding a database

Integrations

Every package and entity

Backup and restore

Protecting your data

Deployments

How templates and the MANIFEST fit together