Skip to main content

​
Why Monk Needs Credentials

Monk follows a Bring Your Own Infrastructure (BYOI) model - everything runs on your cloud accounts and services. Monk needs credentials to provision and manage resources on your behalf. What Monk does with credentials:
  • Provisions cloud infrastructure (VMs, networking, storage)
  • Configures managed services (databases, caches, CDNs)
  • Deploys your applications
  • Monitors and manages resources
Security guarantee:
  • Credentials stored locally and encrypted
  • Never sent to Monk servers
  • Only used for actions you approve
  • You can delete anytime
→ See Security for details on credential protection

​
When Monk Asks for Credentials

Monk requests credentials automatically when needed: 
deploy to AWS
Monk detects you want to use AWS and requests credentials if not already configured. You’ll see a credential form appear in your IDE where you can securely enter the required information.

​
Cloud Provider Credentials

​
AWS Credentials

What you need:
  • AWS Access Key ID
  • AWS Secret Access Key
  • Optional: Default region (e.g., us-east-1)
How to get them:
  1. Log into AWS Console
  2. Navigate to IAM → Users
  3. Click your username (or create new user for Monk)
  4. Go to Security credentials tab
  5. Click Create access key
  6. Choose “Third-party service” as use case
  7. Copy Access Key ID and Secret Access Key
Required permissions: Attach these AWS managed policies to the user:
  • AmazonEC2FullAccess - For VM provisioning
  • AmazonVPCFullAccess - For networking
  • IAMReadOnlyAccess - For checking permissions
Or create a custom policy with: EC2, VPC, S3 (for cluster management). Providing to Monk: When deploying to AWS, Monk will request credentials. Enter them in the secure form that appears. 
deploy to AWS in us-east-1

​
Google Cloud Platform (GCP) Credentials

What you need:
  • Service Account JSON key file
  • Optional: Project ID (auto-extracted from key)
  • Optional: Default region (e.g., us-central1)
How to get them:
  1. Log into GCP Console
  2. Navigate to IAM & Admin → Service Accounts
  3. Click Create Service Account
  4. Name it (e.g., “monk-deployment”)
  5. Grant roles:
    • Compute Admin - For VM management
    • Service Account User - For service operations
  6. Click Done
  7. Click the service account name
  8. Go to Keys tab → Add Key → Create new key
  9. Choose JSON format
  10. Download the JSON file
Providing to Monk: When prompted, select the downloaded JSON file. Monk will extract all necessary information automatically.

​
Microsoft Azure Credentials

What you need:
  • Client ID (Application ID)
  • Client Secret
  • Tenant ID
  • Subscription ID
  • Resource Group name
How to get them:
  1. Log into Azure Portal
  2. Navigate to Azure Active Directory → App registrations
  3. Click New registration
  4. Name it (e.g., “Monk Deployment”)
  5. Click Register
  6. Copy the Application (client) ID and Directory (tenant) ID
  7. Go to Certificates & secrets → New client secret
  8. Create and copy the secret value
  9. Navigate to Subscriptions, copy your Subscription ID
  10. Create or select a Resource Group for Monk to use
Required permissions:
  • Assign Contributor role on the subscription or resource group
Providing to Monk: You can provide Azure credentials via:
  • JSON file containing all fields
  • Individual fields in the credential form

​
DigitalOcean Credentials

What you need:
  • Personal Access Token (API token)
  • Optional: Default region (e.g., nyc1)
How to get them:
  1. Log into DigitalOcean
  2. Click API in left sidebar
  3. Go to Tokens/Keys tab
  4. Click Generate New Token
  5. Name it (e.g., “Monk Deployment”)
  6. Check both Read and Write scopes
  7. Click Generate Token
  8. Copy the token immediately (shown only once)
Providing to Monk: Enter the token when Monk requests DigitalOcean credentials. 
deploy to DigitalOcean

​
Service Provider Credentials

​
MongoDB Atlas

What you need:
  • Organization Name
  • Service Account Client ID (Public Key)
  • Service Account Client Secret (Private Key)
How to get them:
  1. Log into MongoDB Atlas
  2. Click organization name (top left) → Organization Settings
  3. Go to Access Manager → API Keys tab
  4. Click Create API Key
  5. Description: “Monk Deployment”
  6. Set Organization Permissions:
    • Organization Project Creator
    • Project Cluster Manager
    • Project User Admin
  7. Click Next
  8. Copy the Public Key (Client ID) and Private Key (Client Secret)
  9. Save them securely - private key shown only once
  10. Note your Organization Name or ID from Organization Settings
Required access scope: Monk needs these permissions to:
  • Create projects in your organization
  • Provision and manage clusters
  • Create database users for your applications
This is the minimal scope required. Monk cannot access existing projects or data. Providing to Monk: 
use MongoDB Atlas for my database
Monk will request Atlas credentials via secure form. → See MongoDB Atlas Integration for full details

​
Redis Cloud

What you need:
  • Account Key
  • User Key
  • Database Password (Monk can generate this)
How to get them:
  1. Log into Redis Cloud console
  2. Navigate to Account Settings → API Keys
  3. Find your Account Key and User Key
  4. Copy both values
  5. Choose a strong database password (or let Monk generate one)
Providing to Monk: 
use Redis Cloud instead of self-hosted Redis

​
Netlify

What you need:
  • Nothing! Netlify uses OAuth.
How it works:
  1. Tell Monk to deploy to Netlify:
deploy frontend to Netlify
  1. Click Connect Netlify when prompted
  2. Browser opens to Netlify authorization page
  3. Click Authorize to grant Monk access
  4. Automatically redirects back to IDE
  5. Credentials stored securely
No manual token needed - OAuth handles everything.

​
Auth0

What you need:
  • Domain (Management API URL)
  • Management Client ID
  • Management Client Secret
How to get them:
  1. Log into Auth0 Dashboard
  2. Go to Applications → Applications
  3. Click Create Application
  4. Name: “Monk Management”
  5. Type: Machine to Machine
  6. Select Auth0 Management API
  7. Grant all permissions for Applications, Users, and Resource Servers
  8. Click Authorize
  9. Copy Domain, Client ID, and Client Secret
Format domain correctly:
  • Use: your-tenant.auth0.com
  • Not: https://your-tenant.auth0.com/
Providing to Monk: 
use Auth0 for authentication

​
Vercel

What you need:
  • Personal Access Token
  • Optional: Team ID (for team deployments)
How to get them:
  1. Log into Vercel
  2. Go to Settings → Tokens
  3. Click Create Token
  4. Name: “Monk Deployment”
  5. Scope: Choose Full Account or minimal (deploy, project read)
  6. Expiration: Set based on your security policy
  7. Click Create and copy the token
For team deployments:
  • Go to team settings to find Team ID
Providing to Monk: 
deploy frontend to Vercel

​
GitHub (for CI/CD)

What you need:
  • Fine-Grained Personal Access Token
How to get it:
  1. Log into GitHub
  2. Go to Settings → Developer settings
  3. Click Personal access tokens → Fine-grained tokens
  4. Click Generate new token
  5. Name: “Monk CI/CD”
  6. Expiration: Choose based on security needs
  7. Repository access: Select repositories Monk should access
  8. Permissions (on selected repositories):
    • Actions: Read and write
    • Secrets: Read and write
    • Environments: Read and write
    • Contents: Read
    • Metadata: Read
  9. Click Generate token and copy it
Providing to Monk: 
set up CI/CD with GitHub Actions

​
Slack (for Watcher Alerts)

What you need:
  • Incoming Webhook URL
How to get it:
  1. Go to your Slack workspace settings
  2. Navigate to Apps → Add apps
  3. Search for “Incoming Webhooks” and add it
  4. Click Add to Slack
  5. Choose a channel for alerts (e.g., #monk-alerts)
  6. Click Add Incoming WebHooks integration
  7. Copy the Webhook URL (starts with https://hooks.slack.com/...)
Providing to Monk: 
set up watcher
Monk will request the Slack webhook URL during Watcher setup. → See Watcher Setup for complete guide

​
Managing Your Credentials

​
Check Configured Credentials

what credentials do I have configured?
Monk lists all configured providers and shows which ones are ready.

​
Update Existing Credentials

update my AWS credentials
Monk opens the credential form with current values (sensitive fields hidden). Update and save.

​
Remove Credentials

delete my Azure credentials
Monk removes credentials from secure storage. You can re-add them anytime.

​
Security Best Practices

​
1. Use Service Accounts

For production deployments:
  • AWS: Create dedicated IAM user (not your personal account)
  • GCP: Use service account (not user credentials)
  • Azure: Use service principal (not personal account)
  • MongoDB Atlas: Create org-level API key (not personal)
Why: Service accounts can be rotated without affecting your personal access.

​
2. Minimal Permissions

Grant only what Monk needs:
  • Don’t use admin/root credentials
  • Follow principle of least privilege
  • Review permissions lists above for each provider
Why: Limits blast radius if credentials are compromised.

​
3. Rotate Regularly

Recommended schedule:
  • Every 90 days for production credentials
  • Immediately if potentially exposed
  • When team members leave
update [provider] credentials

​
4. Enable MFA

Enable multi-factor authentication on all provider accounts:
  • AWS: Enable MFA on IAM user (even for programmatic access)
  • GCP: MFA on account that manages service accounts
  • Azure: MFA on Azure AD account
  • MongoDB Atlas: MFA on your Atlas account

​
5. Monitor Usage

Check provider audit logs periodically:
  • AWS CloudTrail
  • GCP Audit Logs
  • Azure Activity Log
  • MongoDB Atlas Access Tracking
Look for unexpected API calls or resource changes.

​
6. Team Access

For teams:
  • Use organization features to share access
  • Don’t share personal credentials
  • Each team member should have appropriate role
  • Use service accounts for shared infrastructure

​
Troubleshooting

​
Monk says credentials are invalid

Check:
  1. Verify credentials in provider console
  2. Ensure permissions/roles are granted correctly
  3. Look for typos or extra spaces
  4. For API keys - check they haven’t expired
  5. For service accounts - verify they’re enabled
Try updating: 
update my [provider] credentials
Monk will re-prompt for credentials.

​
Which credentials do I need?

Monk tells you based on what you’re deploying:
  • Cloud provider credentials: Needed when creating clusters (AWS, GCP, Azure, DigitalOcean)
  • Service providers: Needed when using specific integrations (MongoDB Atlas, Netlify, etc.)
  • Application secrets: Custom secrets your application needs (API keys, tokens)
Don’t pre-configure everything - Monk will ask for what’s needed when needed.

​
Can I use multiple cloud accounts?

Currently, Monk supports one set of credentials per provider at a time: To use different accounts:
  • Update credentials before creating clusters
  • Each cluster remembers which account created it
Coming soon: Organization features will support multiple credential sets per provider.

​
Credentials not being accepted

Common issues: AWS:
  • Access keys disabled in IAM console
  • Missing required permissions
  • Region mismatch (if specifying default region)
GCP:
  • Service account disabled
  • JSON key file malformed
  • Missing required roles
Azure:
  • Client secret expired
  • Wrong tenant ID
  • Missing Contributor role
DigitalOcean:
  • Token revoked
  • Insufficient scopes (need Read + Write)
MongoDB Atlas:
  • API key disabled or deleted
  • Wrong organization name/ID
  • Insufficient permissions on API key
Ask Monk for help: 
why are my [provider] credentials not working?