# emma Docs (/docs) ## Release notes [#release-notes] # Coming from the AWS console or Terraform (/docs/ai-console/coming-from) If you manage infrastructure today through a cloud provider's console or with Terraform, emma will feel familiar fast — it keeps the parts that work and changes how you author. This page maps the concepts across so you can get oriented. Whichever you're coming from, the same things are still true: you work with real cloud resources, you review changes before they happen, and you end up with infrastructure-as-code you own. ## If you use the AWS console (or another provider console) [#if-you-use-the-aws-console-or-another-provider-console] The provider console is click-through and single-cloud. emma keeps the live, visual view — [the diagram](/docs/ai-console/concepts/the-diagram) is the counterpart to the console's resource map — but you drive changes by describing them instead of navigating menus, and one view spans every cloud you've connected. * **Navigating menus** becomes **asking the copilot** * **One console per provider** becomes **one conversation across providers** * **Clicking "Launch instance"** becomes a **plan you preview and confirm** ## If you use Terraform [#if-you-use-terraform] Terraform is declarative and reviewable — and emma doesn't take that away. You author by prompt instead of writing HCL, but emma still produces a **plan** you review before it applies (like `terraform plan`), and you can **export** any result back to Terraform. The prompt is a faster front end; the code is still yours. * **Writing HCL** becomes **describing intent**; emma generates the config * **`terraform plan`** becomes the **plan preview** you confirm * **`terraform apply`** becomes **Confirm** — [changes are always gated](/docs/ai-console/concepts/safety-and-confirmations) * **Your `.tf` files** are still available any time via [export](/docs/ai-console/guides/export-to-iac) ## At a glance [#at-a-glance] | | Provider console | Terraform | emma AI Console | | --------------------- | ------------------- | ------------------- | ------------------------------ | | Authoring | click through menus | write HCL | describe intent to the copilot | | Preview before change | limited | `terraform plan` | plan preview on every change | | Apply | click | `terraform apply` | Confirm (always gated) | | Multi-cloud | one console each | per-provider config | one conversation | | Portable IaC out | no | native | export TF / YAML / JSON | | Live visual view | yes | no | the diagram | ## How you'd do a familiar task [#how-youd-do-a-familiar-task] **Try this** — `Create a t3.medium-equivalent VM with 100GB storage in eu-central and show me the plan` You describe the outcome; emma picks the provider-specific details, shows the plan, and waits for your confirm — then you can export the result to Terraform if you want it in your repo. ## FAQ [#faq] **Do I have to stop using Terraform?** No. emma exports standard Terraform (and YAML/JSON), so you can keep a code workflow and use emma to author faster. **Is my infrastructure locked into emma?** No. Everything is real cloud infrastructure in your own accounts, and anything emma builds can be exported as code. **Does emma manage state like Terraform?** emma reads live state from your providers rather than asking you to manage a state file. Import existing resources with [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra). **What about changes I make outside emma?** emma reflects live state, so resources changed elsewhere show up when emma next reads the account. ## What's next [#whats-next] * [Quickstart](/docs/ai-console/quickstart) — try it in about five minutes * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) — the model behind the workflow * [Export to infrastructure-as-code](/docs/ai-console/guides/export-to-iac) — get your code back out # What is emma AI Console (/docs/ai-console) emma AI Console is a conversational interface for your multi-cloud infrastructure. Instead of clicking through a provider console or hand-writing configuration, you tell an AI **copilot** what you want — and emma plans it, shows you a preview, and executes it once you confirm. A live **diagram** keeps a picture of everything you're running, across every cloud you've connected. In a nutshell: * **[The copilot](/docs/ai-console/concepts/the-copilot)** — a chat assistant that reads your infrastructure, answers questions, and makes changes on your behalf. * **[Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt)** — describe intent in plain language; emma turns it into a reviewable plan you can execute and export. * **[The diagram](/docs/ai-console/concepts/the-diagram)** — a live architecture canvas of your real resources, viewable through network, compute, and security lenses. * **[Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations)** — nothing that changes infrastructure happens without your explicit confirmation. ## A console you talk to [#a-console-you-talk-to] Sign in with your emma account and connect a cloud provider, and the copilot can see and manage the same resources you'd find in that provider's console. The difference is how you drive it: you ask for outcomes ("give me a small VM in Frankfurt", "where am I overspending?") rather than navigating menus or memorizing API shapes. emma works across the cloud providers it supports — one conversation can span all of them. ## What you can do [#what-you-can-do] * **Inspect** what's running and how it's connected, in chat or on the diagram * **Deploy** VMs, apps, databases, and Kubernetes workloads by describing them * **Optimize** cost — find waste and cheaper alternatives across providers * **Import** existing infrastructure emma isn't managing yet * **Get alerted** in Telegram or Slack when something needs attention * **Export** anything you build to Terraform, YAML, or JSON ## How it's different [#how-its-different] If you're coming from a cloud provider's console or from Terraform, see [Coming from the AWS console or Terraform](/docs/ai-console/coming-from) for how the concepts map across. ## Explore the docs [#explore-the-docs] Jump into a section to go deeper. # Quickstart (/docs/ai-console/quickstart) emma AI Console lets you manage multi-cloud infrastructure by talking to a copilot: you describe what you want in plain language, emma turns it into a plan, you confirm it, and emma executes — while the diagram keeps a live picture of everything you're running. In this quickstart you'll: 1. Open the console and the copilot 2. Ask the copilot what's already running 3. Create a VM just by describing it 4. See it on the diagram and export it as Terraform **Before you start** you need an emma account and at least one connected cloud provider. If you haven't connected one yet, add it under **Settings → Cloud Providers** first — it takes a minute, then come back here. ## 1. Open the copilot [#1-open-the-copilot] Sign in at [iap.emma.ms](https://iap.emma.ms). You'll land on the **Overview**. Open the copilot from the **emma AI** toggle in the top bar — it docks to the right of the screen and stays with you as you move between the diagram, deployments, and settings. ## 2. Ask what's running [#2-ask-whats-running] Start with a question rather than a command — it's the fastest way to see the copilot and the diagram work together. **Try this** — `What's running in my account right now?` The copilot reads your connected providers and answers in the chat, and the **diagram** fills in with your current resources — VMs, networks, volumes — grouped by provider and region. Click any node to see its details. ## 3. Create a VM by describing it [#3-create-a-vm-by-describing-it] Now make a change. Describe the outcome you want; you don't need to know the provider's exact flavor names or API. **Try this** — `Spin up a small Ubuntu VM in Frankfurt` emma turns this into a **plan** and shows you a **preview** — the exact resource it will create, where, and the estimated cost — before anything happens. Creating, changing, or deleting infrastructure always waits for your **Confirm**. emma never executes a change on its own — read the preview, then confirm. Read the plan preview in the chat — provider, region, size, and cost. **Approve the plan** , then **Confirm & deploy** . emma provisions the VM and streams progress as it goes. When it finishes, the new VM appears in InfraMap. The new VM on the InfraMap diagram, alongside the rest of your infrastructure ## 4. Export it as Terraform [#4-export-it-as-terraform] Everything you build by chatting is real infrastructure you can take with you — this is Infrastructure-as-Prompt. **Try this** — `Export this VM as Terraform` emma generates the `.tf` for the resource you just created. You can also export a whole plan as **Terraform**, **YAML**, or **JSON** — see [Export to infrastructure-as-code](/docs/ai-console/guides/export-to-iac). ## What's next [#whats-next] * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) — the plan → preview → execute → export model * [Deploy an app by chatting](/docs/ai-console/guides/deploy-by-chatting) — go beyond a single VM * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — get notified in Telegram or Slack * [Connect the MCP server](/docs/ai-console/mcp/mcp-server) — drive emma from your own AI tools Stuck? Ask the copilot `How do I ...?` right in the console, or reach the team from the help menu. # Troubleshooting & FAQ (/docs/ai-console/troubleshooting) If something isn't behaving as expected, start here. Each entry is a symptom, its likely cause, and the fix. Still stuck? Ask the copilot `How do I ...?` right in the console, or reach the team from the help menu. ## The copilot can't see my resources [#the-copilot-cant-see-my-resources] **Symptom** — you ask what's running and emma reports nothing, or misses a cloud you use. **Likely cause** — that cloud provider isn't connected, or the connection lost access. **Fix** — connect or reconnect the provider under **Settings → Cloud Providers**, then ask again. To pull in resources emma isn't tracking yet, run [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra). ## My change didn't happen [#my-change-didnt-happen] **Symptom** — you asked emma to create or change something, but nothing changed. **Likely cause** — the change is waiting on your confirmation. emma never applies infrastructure changes on its own. **Fix** — look for the plan preview in the chat and click **Confirm**. See [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## My MCP client doesn't show emma's tools [#my-mcp-client-doesnt-show-emmas-tools] **Symptom** — Claude Desktop, Cursor, or your agent doesn't list the emma tools. **Likely cause** — the server isn't configured, the client wasn't restarted, or the token is missing or invalid. **Fix** — recheck the config against [Connect the MCP server](/docs/ai-console/mcp/mcp-server), confirm `EMMA_TOKEN` is set to a valid key from **Settings → API Keys**, and restart the client. ## An alert never arrived [#an-alert-never-arrived] **Symptom** — a condition you set an alert for occurred, but you weren't notified. **Likely cause** — the delivery channel isn't linked, or the alert routed somewhere you didn't check. **Fix** — confirm the channel is linked ([Telegram](/docs/ai-console/integrations/telegram) / [Slack](/docs/ai-console/integrations/slack)) and that the alert routes there — see [Set up alerts](/docs/ai-console/guides/set-up-alerts). ## A model I want isn't available [#a-model-i-want-isnt-available] **Symptom** — a model doesn't appear in the picker, or a stage fell back to a default. **Likely cause** — the model needs a key your company hasn't added, or multi-provider isn't enabled. **Fix** — check [Choosing models](/docs/ai-console/models/choosing-models); for your own providers, see [Bring your own model keys](/docs/ai-console/models/bring-your-own-keys) (administrator required). ## FAQ [#faq] **Is it safe to let the copilot manage production?** Yes — every change waits for your confirmation, so the copilot can propose but never apply on its own. See [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). **Does emma lock me in?** No. Your infrastructure lives in your own cloud accounts, and anything emma builds can be [exported as code](/docs/ai-console/guides/export-to-iac). **Which clouds does emma support?** The major providers; connect them under **Settings → Cloud providers**. One conversation spans all connected clouds. **Can I use emma from my own tools?** Yes — the [MCP server](/docs/ai-console/mcp/mcp-server) exposes your infrastructure to any MCP-compatible client. ## What's next [#whats-next] * [Quickstart](/docs/ai-console/quickstart) — the basics, start to finish * [What is emma AI Console](/docs/ai-console) — the concepts in one place # Platform (/docs/platform) Guides for provisioning compute and storage, organizing work into projects, managing your company, and connecting your own tooling. # Billing for Azure Services (External Services) (/docs/release-notes/2024-04-29) ## Product features [#product-features] ### Billing for Azure services (external services) [#billing-for-azure-services-external-services] We’ve successfully completed the billing integration for Azure services within the External Services module. This update ensures accurate tracking and reporting of costs associated with Azure services, providing users with detailed billing information for better financial management and resource optimization. ## Fixes / internal improvements [#fixes--internal-improvements] ### Internal error handling [#internal-error-handling] Enhancement to system reliability. # Updated API & CLI (/docs/release-notes/2024-05-13) ### Updated API & CLI [#updated-api--cli] We’ve launched the initial release of our newly reworked API and CLI. This update provides a more streamlined, efficient interface for interacting with the platform, enabling enhanced automation and integration capabilities. The reworked API and CLI bring improved performance, better structure, and expanded functionality, laying the foundation for future feature enhancements. ### Universal action notification [#universal-action-notification] Initial release of Universal Action Notification for virtual machine (VM) actions. This feature provides users with real-time alerts and notifications for key VM operations, ensuring users are informed of important events and actions as they occur, improving operational awareness and responsiveness. # Universal Action Control Display - Unified UI for Action Permissions (/docs/release-notes/2024-05-27) ## Product features [#product-features] ### Universal action control display — unified UI for action permissions [#universal-action-control-display--unified-ui-for-action-permissions] We’ve unified the display of UI controls for initiating actions based on user permissions and system availability. Key updates include: ### Permission-based visibility [#permission-based-visibility] Users without the required project-level or company-level permissions will no longer see the control for actions they cannot perform. ### Disabled controls with explanations [#disabled-controls-with-explanations] When an action is temporarily unavailable due to factors like compute instance status or service unavailability, users will see the control in a disabled state with a tooltip explaining the reason. ### Cost transparency [#cost-transparency] For actions that impact the cloud bill, the exact cost or an "up to" maximum will be displayed. If the cost is unknown, no amount will be shown. ### Limit enforcement [#limit-enforcement] Users will be prevented from initiating actions that would exceed project cost or resource limits. Disabled controls will include tooltips explaining the restriction. This update ensures a clearer, more intuitive action initiation process, preventing unauthorized or invalid actions while providing clear explanations. ## Fixes / internal improvements [#fixes--internal-improvements] ### Internal services scaling [#internal-services-scaling] Completed scaling internal services for improved system performance and reliability. ### Network architecture update [#network-architecture-update] New network architecture beta testing is underway. # Updated Terraform Provider (/docs/release-notes/2024-06-10) ## Product features [#product-features] ### Updated Terraform provider [#updated-terraform-provider] We’ve completely reworked our Terraform Provider, starting from support for virtual machines (VMs). This overhaul enhances the provider’s capabilities, allowing users to automate the creation and management of VMs through Terraform, improving infrastructure-as-code workflows and cloud resource management. ## Fixes / internal improvements [#fixes--internal-improvements] ### Unique Kubernetes node names [#unique-kubernetes-node-names] Implemented to prevent node name duplication. ### Process metrics for Windows VMs [#process-metrics-for-windows-vms] We’ve enhanced support for metrics on Windows virtual machines (VMs). This update provides more detailed and accurate monitoring of Windows VM performance, enabling better insight into resource utilization and system health for improved management and optimization. # Managed K8s Cluster with Multi-cloud Network (/docs/release-notes/2024-06-24) ### Managed K8s cluster with multi-cloud network [#managed-k8s-cluster-with-multi-cloud-network] Beta testing in progress for Kubernetes clusters integrated with the new multi-cloud network setup. ### SG rework [#sg-rework] Significant updates to Security Groups. ### vCenter integration [#vcenter-integration] Beta testing for VM CRUD operations on Center. # Managed K8s Cluster with Multi-cloud Network (/docs/release-notes/2024-07-08) ## Product features [#product-features] ### Managed K8s cluster with multi-cloud network [#managed-k8s-cluster-with-multi-cloud-network] We’ve completed the initial release of managed kubernetes (K8s) clusters integrated with a new multi-cloud network setup. This feature enables users to deploy and manage kubernetes clusters across multiple cloud environments, providing greater flexibility and scalability in their cloud infrastructure. ## Fixes / internal improvements [#fixes--internal-improvements] ### Resource hub enhancements [#resource-hub-enhancements] Improved tags and UI fixes for a smoother experience. # Gcore and DigitalOcean Subnetworks - Custom Subnetworks and Private IPs (/docs/release-notes/2024-07-22) ## Product features [#product-features] ### Gcore and DigitalOcean subnetworks — custom subnetworks and private IPs [#gcore-and-digitalocean-subnetworks--custom-subnetworks-and-private-ips] We’ve completed the integration of custom subnetworks and private IP address functionality for Gcore and DigitalOcean. This update allows users to configure and manage subnetworks more effectively within these platforms, enhancing flexibility and control over network architecture. ### Resource hub enhancements — tag-based filtering [#resource-hub-enhancements--tag-based-filtering] We’ve added a powerful new filtering feature to the Resource Hub, enabling users to filter resources by tags. This enhancement allows for more efficient navigation and organization of the company’s aggregated resources, helping users quickly locate specific assets based on custom tags. ## Fixes / internal improvements [#fixes--internal-improvements] ### Multi-cloud network and K8s cluster [#multi-cloud-network-and-k8s-cluster] Minor adjustments of internal logic. # Resource Hub for Managed Kubernetes (/docs/release-notes/2024-08-05) ### Resource hub for managed Kubernetes [#resource-hub-for-managed-kubernetes] We’ve enhanced the Resource Hub by integrating Kubernetes nodes information. This feature provides an aggregated view of all company resources, including managed Kubernetes clusters, making it easier to access and manage detailed K8s data within the Resource Hub. # External API Statistical Data (/docs/release-notes/2024-08-20) ## Product features [#product-features] ### External API statistical data [#external-api-statistical-data] We’ve introduced a new method to the External API that allows users to request and retrieve statistical data. This addition enhances data accessibility, enabling easier integration of key metrics into external systems for more efficient analysis and reporting. ## Fixes / internal improvements [#fixes--internal-improvements] ### Multi-cloud network statistics [#multi-cloud-network-statistics] Addressed a bug where dashboards were not updating prices after removing Network/Connection. ### Managed Kubernetes clusters external API (beta testing) [#managed-kubernetes-clusters-external-api-beta-testing] Addressed issues with cluster updates and creation of Auto-Scaling (AS) groups using GCP nodes. ### Invoice processing [#invoice-processing] Blocked changing the company currency after the first order to prevent discrepancies. # Managed Kubernetes Cluster in External API (/docs/release-notes/2024-09-09) ### Managed Kubernetes cluster in external API [#managed-kubernetes-cluster-in-external-api] We have expanded the External API to include full support for managed Kubernetes (K8s) clusters. Users can now perform essential operations such as listing clusters, retrieving cluster details, adding new clusters, editing existing clusters, and deleting clusters. Additionally, domain-specific operations are supported, providing more robust and flexible management of K8s clusters directly through the API, streamlining automation and integration with external systems. ### Multi-cloud network enhancements — cost tracking across regions [#multi-cloud-network-enhancements--cost-tracking-across-regions] We’ve introduced enhancements to track and store company expenses for multi-cloud networks across all the regions. Portal now stores detailed cost data, summarizing expenses for connectivity centers, cloud connections within each provider, and cross-region connections. ### Quota management (Azure) — error handling for quota exceedance [#quota-management-azure--error-handling-for-quota-exceedance] In this initial phase, we’ve implemented improved handling of quota-related errors for Azure. Rather than displaying quota tables or limits, the system will now accurately parse and process provider quota exceedance errors. When a quota is exceeded, a clear red toast notification will appear in the interface, ensuring users are promptly informed of the issue and can take corrective action. ### Default network setup for AWS, GCP, Azure [#default-network-setup-for-aws-gcp-azure] We’ve extended the default configurations for non-multi-cloud networking across AWS, GCP, and Azure. This update simplifies the setup process by providing pre-configured default settings, enabling faster and more efficient deployment of cloud resources within single-cloud environments. ### vCenter onboarding — beta version released [#vcenter-onboarding--beta-version-released] We have launched the beta version of our vCenter Onboarding, integrating on-premises VMware solutions with our platform. This allows users to seamlessly onboard and manage VMware virtual machines (VMs) within the cloud management system. The beta release provides early access to this feature, enabling a streamlined hybrid environment experience while gathering user feedback for further improvements. # Project limits (/docs/release-notes/2024-09-17) ## Product features [#product-features] ### Project limits [#project-limits] A new feature allowing users with the “Manage limits” permission to set limits on creating and transferring virtual machines (VMs) within a project. Users can specify allowed or disallowed locations and providers for VMs. By default, all are allowed, but once limits are set, restricted locations and providers are hidden during VM creation. These restrictions also apply to requests via External API and Terraform, with failed requests returning detailed validation error messages explaining the enforced limits. ### vCenter onboarding — integration with VMware solutions [#vcenter-onboarding--integration-with-vmware-solutions] We’ve integrated on-premises VMware solutions with our platform, enabling seamless onboarding of VMware environments into our cloud management system. This integration simplifies resource management, allowing users to efficiently manage VMware virtual machines (VMs) alongside their cloud infrastructure, ensuring a unified and streamlined experience across hybrid environments. ## Fixes / internal improvements [#fixes--internal-improvements] ### Portal update [#portal-update] Updated frontend framework bringing enhanced performance, improved maintainability. # Location and Provider Limits for VMs (/docs/release-notes/2024-09-30) ### Location and provider limits for VMs [#location-and-provider-limits-for-vms] Users with the “Manage limits” permission can now define allowed or disallowed locations and providers for creating and transferring VMs within a project. By default, all locations and providers remain permitted, but any limits imposed will hide forbidden options in the wizard and block related API or Terraform calls, returning clear error messages to explain the restrictions. ### New client onboarding [#new-client-onboarding] We have successfully onboarded our new client, ensuring a smooth transition into our platform with a streamlined setup, clear documentation, and dedicated support for their immediate operational needs. ### AWS quota exceeding error notifications [#aws-quota-exceeding-error-notifications] We now display notifications when AWS quotas are exceeded, ensuring users quickly see and address resource limitations. This proactive alerting helps avoid potential service interruptions and improves overall resource management. ### Mass VM actions with real-time validation [#mass-vm-actions-with-real-time-validation] We now enable mass actions on multiple VMs in the VMs section and Advisors. The system provides real-time status updates and sends text notifications upon completion, ensuring a clear, consistent experience for all VM operations. # AWS and Azure Subnetworks via External API (/docs/release-notes/2024-10-14) ### AWS and Azure subnetworks via external API [#aws-and-azure-subnetworks-via-external-api] We have introduced subnetwork functionality for AWS and Azure through the emma External API, enabling users to optionally set a private IP when creating VMs. The IP is automatically provisioned on VM creation and removed upon termination, eliminating the need for separate IP management. ### New “expense analysis” dashboard [#new-expense-analysis-dashboard] We have introduced a dedicated “Expense Analysis” dashboard to help users plan expenses and optimize costs. It provides both historical spending data and expense forecasts, highlighting the profitability of emma’s recommendations for more informed financial decisions. ### New domain verification and dynamic hostname allocation for Kubernetes [#new-domain-verification-and-dynamic-hostname-allocation-for-kubernetes] We introduced an application that verifies user domains within the Portal (currently supporting one domain from the UI) and automatically assigns FQDNs when a load balancer service is created in the cluster. If multiple ingress controllers are present, this application updates Cloudflared agent configurations so that each domain routes to the correct ingress controller, simplifying domain management and scaling. ### Session idle timeout [#session-idle-timeout] We introduced an automatic session timeout that logs users out after a period of inactivity, enhancing security by reducing the risk of unauthorized access to idle sessions. # GCP Subnetworks via External API (/docs/release-notes/2024-11-12) ## Product features [#product-features] ### GCP subnetworks via external API [#gcp-subnetworks-via-external-api] We have introduced subnetwork functionality for GCP through the emma External API, enabling users to optionally set a private IP when creating VMs. The IP is automatically provisioned on VM creation and removed upon termination, eliminating the need for separate IP management. ### Dashboard data filtering [#dashboard-data-filtering] emma now offers a built-in data filtering capability on the dashboard, allowing users to tailor their view and focus on the most relevant information ## Fixes / internal improvements [#fixes--internal-improvements] ### Dashboard data filtering [#dashboard-data-filtering-1] emma now offers a built-in data filtering capability on the dashboard, allowing users to tailor their view and focus on the most relevant information. ### Streamlined external services integration [#streamlined-external-services-integration] External services functionality has been fully adapted for dedicated Azure/AWS/GCP subaccounts per project, ensuring seamless alignment with emma’s permissions and billing systems. ### Project-level multi-cloud network [#project-level-multi-cloud-network] emma’s multi-cloud networking feature is now defined at the project level rather than the company level, providing more granular control over resource connectivity and isolation. # AWS Integration Overview (/docs/release-notes/2024-11-26) ### AWS integration overview [#aws-integration-overview] The External Integrations section now includes an AWS provider card that displays connection status. Once connected, the External Services section shows all available AWS services. ### Tag-based grouping and filtering [#tag-based-grouping-and-filtering] emma offers the option to group and filter data by user-defined tags, as well as by location, enabling more focused and efficient data management. ### Spot instance limits [#spot-instance-limits] Users with “Manage limits” permission can now set allowed providers and locations for Spot instances at the project level. Disallowed providers or locations are hidden in the Spot creation wizard and blocked via External API, returning clear validation error messages. ### North american Kubernetes deployment [#north-american-kubernetes-deployment] We introduced a North American deployment option for emma Kubernetes clusters, complementing the existing European region for broader geographic coverage. # Kubernetes Cluster Creation Limits (/docs/release-notes/2024-12-11) ### Kubernetes cluster creation limits [#kubernetes-cluster-creation-limits] Users with the “Manage limits” permission can now specify allowed providers and locations for creating (or editing) Kubernetes clusters in a project. Any disallowed options are hidden in the cluster creation wizard and blocked by the External API, returning clear validation errors. ### Domain verification and FQDN assignment [#domain-verification-and-fqdn-assignment] We added an application that verifies user domains (one at a time in the current UI) and automatically allocates an FQDN when a load balancer service is created in a cluster. If multiple ingress controllers exist, the application updates Cloudflared agent configurations to route each domain to the appropriate controller. This enables users to see which services are externally exposed, add multiple domains, and operate multiple ingress controllers simultaneously. # Managed K8s Cluster in Terraform (/docs/release-notes/2024-12-27) ## Product features [#product-features] ### Managed K8s cluster in Terraform [#managed-k8s-cluster-in-terraform] We’ve added support for provisioning managed Kubernetes clusters through the emma Terraform provider, simplifying cluster setup and administration. ### Project-level external services [#project-level-external-services] The external services feature is now fully aligned with dedicated Azure/AWS/GCP subaccounts per project, ensuring complete integration with emma’s permissions and billing. Additionally, the External Services section has been moved to the project level for more streamlined management. ## Fixes / internal improvements [#fixes--internal-improvements] ### Code improvements [#code-improvements] We introduced various optimizations to enhance performance, maintainability, and overall code quality. # 17 Jan 2025 (/docs/release-notes/2025-01-17) Minor bug fixes and performance improvements # 5 Feb 2025 (/docs/release-notes/2025-02-05) Minor bug fixes and performance improvements # 17 Feb 2025 (/docs/release-notes/2025-02-17) Minor bug fixes and performance improvements # 3 Mar 2025 (/docs/release-notes/2025-03-03) Minor bug fixes and performance improvements # Improved VM Volume Management (/docs/release-notes/2025-03-17) ### Improved VM volume management [#improved-vm-volume-management] We have introduced the option to view and manage all volumes attached to a VM. Users can attach, remove, clone, transfer, and back up volumes both in the user interface and through our External API. Our processes now fully support multiple volumes, ensuring a smooth experience without any noticeable changes in the UI. ### Start/stop for spot instances [#startstop-for-spot-instances] We have reintroduced the ability to start and stop spot instances, along with a new “PREEMPTED” status for instances interrupted by the provider. Users can also change the maximum bid price for AWS and Azure spot instances that are powered off or in “PREEMPTED” state, preserving data and offering enhanced cost control. ### Multi-cloud account set for projects: [#multi-cloud-account-set-for-projects] We’ve successfully integrated a streamlined process for selecting an account set, (GCP project, AWS account, and Azure subscription) at project creation. This approach allows multiple projects to share resources across a multi-cloud network or stay completely isolated under separate account sets. Once chosen, the account set remains fixed, ensuring clarity in resource ownership and connectivity. # New User-Level “Event Logs” Page (/docs/release-notes/2025-03-31) ### New user-level “event logs” page [#new-user-level-event-logs-page] We introduced a dedicated user-level “Event Logs” page that displays all actions performed by the user, offering clearer visibility and improved tracking of individual events. ### Start/stop for spot instances [#startstop-for-spot-instances] We added the ability to start and shut down GCP spot instances, including a new “PREEMPTED” status for instances interrupted by the provider, ensuring data is preserved and enabling more flexible cost control. ### Expanded estore application list [#expanded-estore-application-list] We have widened the selection of applications and configurations available to emma users in the eStore. This enhanced catalog provides greater flexibility and choice when selecting tools to optimize workflows and resource usage. # 14 Apr 2025 (/docs/release-notes/2025-04-14) Minor bug fixes and performance improvements # Volume Management Enhancements (/docs/release-notes/2025-04-30) ### Volume management enhancements [#volume-management-enhancements] emma now features a project-level **Volumes** page that lists every disk across the project, along with a dedicated detail page for each individual volume. Users can create, attach, detach, and delete single data volumes from these views, making storage administration faster and more intuitive. ### Improved VM volume management [#improved-vm-volume-management] We have introduced the option to view and manage all volumes attached to a VM. Users can attach, remove, clone, transfer, and back up volumes both in the user interface and through our External API. Our processes now fully support multiple volumes, ensuring a smooth experience without any noticeable changes in the UI. # Improved Quota View and Request Experience (/docs/release-notes/2025-05-13) ### Improved quota view and request experience [#improved-quota-view-and-request-experience] In this update, managing your quotas just got easier. You can now see a full list of all your available quotas, including their limits and how much you're currently using—all in one clear, organized page. This makes it simple to keep track of your resources and avoid running into unexpected limits. If you need more quota, you can now request an increase right from the same page by sending a support ticket to Emma Technical Support. It's a faster, more convenient way to get what you need. Overall, this improvement gives you better visibility and control, helping you plan and scale your resources with confidence. ### VM volume management [#vm-volume-management] We’ve added support for new providers to give you even more flexibility # 26 May 2025 (/docs/release-notes/2025-05-26) We made the expense analysis dashboards easier and faster to use, added a cost rate-based forecast feature with the ability to show or hide it, and improved logs with additional event tracking. # Hetzner support — Expanded cloud coverage (/docs/release-notes/2025-06-06) ### Hetzner support — expanded cloud coverage [#hetzner-support--expanded-cloud-coverage] emma now includes Hetzner as a supported cloud provider, giving you access to additional infrastructure options for your workloads. ### Web terminal — connect existing machines [#web-terminal--connect-existing-machines] You can now enable Web Terminal access on machines where it wasn't configured at creation time, including machines that have been running for a while. No need to recreate the machine to get terminal access. ### Init scripts — run scripts on machine startup [#init-scripts--run-scripts-on-machine-startup] You can now attach an init script to a Virtual Machine or SPOT instance at configuration time. The script runs automatically right after the machine is created, making it easier to provision and configure machines without manual intervention. # The new AWS bare-metal vCPU type has been added (/docs/release-notes/2025-06-10) ### The new AWS bare-metal vcpu type has been added [#the-new-aws-bare-metal-vcpu-type-has-been-added] You can now create AWS bare-metal instances. Your VM runs straight on the physical CPU cores without a hypervisor in the way, so performance is steady and fast. It’s ideal for tasks that require every millisecond, such as trading systems, large databases, real-time analytics, or per-core licensed software. # 24 Jun 2025 (/docs/release-notes/2025-06-24) Minor Bug Fixes and Performance Improvements # OVHcloud Integration (/docs/release-notes/2025-07-08) ### Ovhcloud integration [#ovhcloud-integration] Our platform now supports OVHcloud, one of Europe’s most trusted cloud service providers. Users can create and manage OVHcloud virtual machines directly from emma portal. # Event Logs Filtering (/docs/release-notes/2025-07-21) ### Event logs filtering [#event-logs-filtering] Our platform now enables filtering on the ‘Event logs’ page. Users can easily sort and refine event log data directly within the emma portal for improved visibility and management. # Open Event Logs from Notifications (/docs/release-notes/2025-08-05) ### Open event logs from notifications [#open-event-logs-from-notifications] emma now allows users to open the user-level Event Logs page directly from a notification, providing quicker access to detailed activity information and easier event tracking. # OVHcloud Recommendations (/docs/release-notes/2025-08-19) ### Ovhcloud recommendations [#ovhcloud-recommendations] You can now generate performance and resource optimization recommendations for OVHcloud VMs and application instances. Based on monitoring data, emma provides insights to improve efficiency and reduce costs — including utilization, resizing, and cleanup suggestions. Available under Project / Virtual Machines / Advisor and Project / Applications / Advisor. ### External API – action logs [#external-api--action-logs] The External API now allows users to retrieve and filter logs of actions performed by the API service application. The results are paginated for easier navigation. Logged events include operations on virtual machines, security groups, spot instances, Kubernetes clusters, and SSH keys. Actions performed directly in the emma portal are not included in these logs. # Rename resources directly in emma (/docs/release-notes/2025-09-02) ### Rename resources directly in emma [#rename-resources-directly-in-emma] You can now change the name of your resources — including VMs, Spots, and application nodes — directly in emma after creation. This update lets you organize and manage your resources more clearly without affecting their names on the cloud provider side. # 16 Sep 2025 (/docs/release-notes/2025-09-16) Minor Bug Fixes and Performance Improvements. # Create cost-efficient HDD Data Volumes (/docs/release-notes/2025-09-30) ### Create cost-efficient HDD data volumes [#create-cost-efficient-hdd-data-volumes] You can now create HDD Data Volumes — ideal for large, low-access datasets, backups, and archives. Gain reliable, high-capacity storage at a lower cost while keeping your data seamlessly integrated across your cloud environments. Available on AWS, Azure, and GCP. ### View initial username and SSH key name in vm/spot details [#view-initial-username-and-ssh-key-name-in-vmspot-details] You can now see the initial username and SSH key name specified during VM/Spot creation directly in the VM/Spot details. This enhancement improves visibility and makes it easier to verify access credentials without leaving the VM page. # Project Groups (Improved Management Experience) (/docs/release-notes/2025-10-14) ### Project groups (improved management experience) [#project-groups-improved-management-experience] The Account Sets feature has been reworked and renamed to Project Groups to make administration more intuitive and user-friendly. With a clearer structure and dedicated sub-tab under Company → Settings, users can easily organize, create, rename, and delete project groups directly from the interface. This change simplifies project management, improves navigation, and helps users maintain a more transparent and structured workspace. ### Ipv6 connectivity [#ipv6-connectivity] Virtual machines are now automatically accessible via IPv6, ensuring reliable connectivity across modern network environments. No additional configuration is required, enabling smoother integration with IPv6-compatible systems and improved support for future-ready infrastructure. ### Expanded network options for Kubernetes clusters [#expanded-network-options-for-kubernetes-clusters] We’ve introduced the Internet Connect network option for Azure, AWS, and GCP in the EU region, expanding connectivity choices for Kubernetes clusters. The former emma Multi-Cloud feature has been renamed to Direct Connect, with its functionality unchanged. Currently, VPN (Internet Connect) access is available for Demo accounts only. If you’d like to join the beta testing, please contact [**support@emma.ms**](mailto:support@emma.ms). # IONOS Virtual Machines (Full Lifecycle Management) (/docs/release-notes/2025-10-28) ### IONOS virtual machines (full lifecycle management) [#ionos-virtual-machines-full-lifecycle-management] Users can now create and manage both Linux and Windows virtual machines on the IONOS cloud platform directly through the emma interface. Supported operations include creation, deletion, reboot, start, and shutdown, enabling full lifecycle control. Users can also edit compute configurations — adjusting CPU, RAM, and other performance parameters without recreating the VM. # K8s Internet Connect — Now Available for All Customers (/docs/release-notes/2025-11-11) ### K8s internet connect — now available for all customers [#k8s-internet-connect--now-available-for-all-customers] The Internet Connect network option is now open to all customers, expanding beyond its previous Demo-only availability. This enhancement enables users in the EU deployment region to seamlessly configure and manage Kubernetes clusters with Internet connectivity across AWS, Azure, and GCP providers. ### Ipv6 connectivity — enabled for AWS, Azure, DigitalOcean, and GCP [#ipv6-connectivity--enabled-for-aws-azure-digitalocean-and-gcp] Building on our earlier rollout, IPv6 Connectivity is now fully supported across all major providers — AWS, Azure, DigitalOcean, and GCP. # 25 Nov 2025 (/docs/release-notes/2025-11-25) Minor Bug Fixes and Performance Improvements # Allocation Optimizer: Multi-Cloud Cost Analytics (/docs/release-notes/2025-12-05) ### Allocation optimizer: multi-cloud cost analytics [#allocation-optimizer-multi-cloud-cost-analytics] emma introduces the Allocation Optimizer, an analytical feature that showcases the value of multi-cloud infrastructure through clear cost insights and optimization scenarios. It analyzes cost-generating resources only at the Company or Project level, respects user permissions, and supports filtering by projects, tags, services, providers, regions, locations, and data centers. emma visualizes current (“as is”) vs optimized (“to be”) costs, highlights required changes, potential savings, and the most impactful optimization actions — all within user-defined constraints. # GPU Virtual Machines — Now Available for Compute-Intensive Workloads (/docs/release-notes/2025-12-23) ### GPU virtual machines — now available for compute-intensive workloads [#gpu-virtual-machines--now-available-for-compute-intensive-workloads] GPU-powered Virtual Machines are now available on the emma platform, giving customers access to hardware-accelerated compute for demanding workloads such as AI and machine learning training, inference, rendering, and large-scale parallel processing. By leveraging GPUs, teams can significantly reduce training and processing times, improve performance for parallel workloads, and achieve greater efficiency compared to CPU-only virtual machines. We’re launching GPU support with AWS GPU instances and will continue to expand availability by adding additional providers across the platform over time. # Sign Up with Google — Faster Access to the Platform (/docs/release-notes/2026-01-21) ### Sign up with Google — faster access to the platform [#sign-up-with-google--faster-access-to-the-platform] Users can now sign up using their Google account, making onboarding faster and frictionless. This update removes manual registration steps and helps teams get started with the platform in just a few clicks. ### GPU virtual machines — now available via external API [#gpu-virtual-machines--now-available-via-external-api] GPU-powered Virtual Machines are now accessible through the External API, enabling programmatic provisioning and management of hardware-accelerated compute for AI, machine learning, inference, rendering, and other compute-intensive workloads. API support allows teams to fully automate GPU VM lifecycle operations and integrate GPU resources directly into existing workflows, CI/CD pipelines, and internal tooling—making it easier to scale high-performance workloads without manual setup. # Workflow Automation — Create and Run Workflows (/docs/release-notes/2026-03-11) ### Workflow automation — create and run workflows [#workflow-automation--create-and-run-workflows] You can now create, edit, and manage workflows directly in the platform with full CRUD support. Workflows can also be executed on demand, launching a shell script on a newly provisioned Linux Virtual Machine for faster infrastructure automation. ### CloudStack support — open-source virtualization management [#cloudstack-support--open-source-virtualization-management] emma now supports CloudStack orchestration, enabling enterprises to provision and manage Virtual Machines and GPU Virtual Machines through open-source virtualization environments. This extends emma’s multi-cloud platform with unified VM lifecycle management across CloudStack and public cloud providers. ### GPU monitoring — visibility into GPU usage [#gpu-monitoring--visibility-into-gpu-usage] GPU usage monitoring is now available in emma, giving teams better visibility into GPU consumption and helping improve operational oversight for compute-intensive workloads. ### Allocation optimizer for Kubernetes nodes — smarter placement recommendations [#allocation-optimizer-for-kubernetes-nodes--smarter-placement-recommendations] Allocation Optimizer now supports Kubernetes nodes, including static and autoscaling group nodes. Teams receive actionable recommendations for better provider and location placement across multi-cloud environments. ### Multi-cloud Kubernetes storage — cloud-agnostic persistent volumes [#multi-cloud-kubernetes-storage--cloud-agnostic-persistent-volumes] You can now use a single cloud-agnostic storage class for Kubernetes Persistent Volumes, while emma automatically maps it to the correct provider-specific storage class. This simplifies storage management across clouds. ### Nebius support — expanded cloud coverage [#nebius-support--expanded-cloud-coverage] emma now includes Nebius support, giving teams access to additional cloud capacity for AI and high-performance workloads. This expands deployment options and provides more flexibility when selecting infrastructure across providers. # GPU for spot instances — Cost-efficient GPU workloads (/docs/release-notes/2026-04-30) ### GPU for spot instances — cost-efficient GPU workloads [#gpu-for-spot-instances--cost-efficient-gpu-workloads] You can now run GPU workloads on spot instances on AWS and GCP, significantly reducing the cost of compute-intensive tasks like model training and batch processing. ### Workflows — spot resources support [#workflows--spot-resources-support] Spot instances can now be included in Workflows, making it easier to build and reuse cost-optimized infrastructure templates across your projects. ### Advisor 2.0 — smarter recommendations and reallocation advice [#advisor-20--smarter-recommendations-and-reallocation-advice] The Advisor now provides clearer, more actionable recommendations. "Increase load" suggestions have been reworked to reduce confusion, and you can now receive reallocation advice to better distribute workloads across providers and locations. ### Cost breakdown dashboard — consolidated expense analytics [#cost-breakdown-dashboard--consolidated-expense-analytics] You can now see exactly where your cloud spend is going — broken down by project, service, provider, and region — all in one place in Analytics Hub. Drill into the cost hierarchy to identify the biggest cost drivers and navigate directly to the resources responsible for your expenses. ### Multi-cloud network — external API support [#multi-cloud-network--external-api-support] Multi-cloud network resources are now available through the External API, giving you the ability to manage network configurations programmatically as part of your automation workflows. # Workflow Execution Visibility — Track workflows on your resources (/docs/release-notes/2026-07-21) ### Workflow execution visibility — track workflows on your resources [#workflow-execution-visibility--track-workflows-on-your-resources] Virtual machines and SPOT instances deployed via a workflow now show the workflow name and a direct link to it on the resource page, so you can always trace back how a machine was provisioned. ### Default workflows — ready-to-use scripts by emma [#default-workflows--ready-to-use-scripts-by-emma] The workflow list now includes a set of default workflows maintained by emma. Use them as-is to spin up virtual machines and SPOT instances, or as a starting point for building your own custom workflows. ### Kubernetes cluster status redesign — clearer status tracking [#kubernetes-cluster-status-redesign--clearer-status-tracking] Kubernetes cluster, node, and autoscaling group statuses have been redesigned for better clarity. Provisioning now runs in parallel, and clusters automatically enter a DEGRADED state when a node fails post-creation. You can also report issues directly from individual nodes or the cluster level for faster support escalation. # Provider Onboarding — Bring your existing cloud accounts into emma (/docs/release-notes/2026-08-17) ## Product features [#product-features] ### Provider onboarding — bring your existing cloud accounts into emma [#provider-onboarding--bring-your-existing-cloud-accounts-into-emma] You can now connect your existing AWS, GCP, and Azure accounts to emma yourself, without going through support. Use BYOA to link an account you already have, or request an emma-managed account and let us provision it for you — both options are available right from the new Manage Providers page. Once connected, discover and import your existing resources so you can manage them through emma alongside everything else. Digital Ocean and Gcore come connected by default, so every new Project Group is ready to use from the moment you create it. ## Improvements [#improvements] ### Cost Breakdown — clickable widgets [#cost-breakdown--clickable-widgets] You can now click any segment, tile, or row in the Cost Breakdown dashboard to highlight that entity, along with everything related to it, across all four widgets at once. This gives you an instant view of how a specific project, service, provider, or resource breaks down across every dimension, without cross-referencing charts manually. Turn a highlighted entity into a filter with one click using Apply as filter, and clear the highlight anytime with a second click or the X in the header. ### Cost Breakdown — now your landing page [#cost-breakdown--now-your-landing-page] Signing in to a company or project now takes you straight to the Cost Breakdown dashboard, putting your most important cost data front and center the moment you land. Combined with the new click-to-explore interactivity, you can start digging into what's driving your costs immediately. ### Autoscaling node group — full spot support [#autoscaling-node-group--full-spot-support] You can now run autoscaling node groups entirely on SPOT instances, with no on-demand nodes required, for maximum cost savings on flexible workloads. If you need a guaranteed baseline of on-demand capacity, you can still set that minimum yourself — the choice is fully in your control. # Release notes (/docs/release-notes) # Audit log (/docs/ai-console/concepts/audit-log) [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) decides whether a change happens. The audit log is the durable record of what did. Together they answer the two questions every security and compliance review asks: can someone change this without approval, and can we see who did what after the fact. In a nutshell: * **State-changing actions are recorded** — creates, modifications, deletes, and the approvals behind them * **Sensitive reads too** — some read actions, such as accessing stored credentials, are recorded on purpose * **Scoped to your company** — you only ever see your own tenant's events * **Kept for 365 days** by default — operator-tunable * **Admin-only** — owners and admins can read the log ## What gets recorded [#what-gets-recorded] Each entry captures who did what, to which resource, and when: | Field | What it is | | ----------------------------- | -------------------------------------------------------------------------------- | | `action` | the event, e.g. `deploy_repo.success` — dotted, so related events share a prefix | | `userId` | who performed it | | `resourceType` / `resourceId` | what it acted on | | `details` | optional structured context for the event | | `ipAddress` | where the request came from | | `createdAt` | when it happened | Every event also carries the company it belongs to, so the log is always tenant-scoped. ## Who can read it [#who-can-read-it] Reading the audit log requires an **owner** or **admin** role. It is tenant-isolated by design: the company is always taken from your session, never from a request parameter, so one company can never read another's log. ## Reading the log [#reading-the-log] There is no in-product audit-log screen today; admins read the log through the API: ``` GET /api/audit-log ``` All filters are optional and combine: | Query param | Effect | | ----------------------------- | ----------------------------------------------------------------------------------------- | | `action` | exact match on a single event | | `actionPrefix` | every event under a prefix, e.g. `deploy_repo.` (mutually exclusive with `action`) | | `userId` | events by one actor | | `resourceType` / `resourceId` | events touching a specific resource | | `from` / `to` | a time window (Unix milliseconds, or an ISO date); `from` is inclusive, `to` is exclusive | | `limit` | page size, 1–200 (default 50); a value outside that range is rejected | | `cursor` | the `nextCursor` from the previous page | Events come back newest-first with a `nextCursor` for paging; when `nextCursor` is `null`, you've reached the end. Authenticate the same way as any other emma API call — see [Bring your own model keys](/docs/ai-console/models/bring-your-own-keys) for where credentials live, and your account's API settings for a service token. ## Retention [#retention] Entries are kept for **365 days** by default and pruned on a rolling schedule. Retention is a single global setting an operator can tune; there is no per-tenant retention override in this version. ## What's next [#whats-next] * [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) — the gate that decides whether a change runs * [The copilot](/docs/ai-console/concepts/the-copilot) — what proposes the changes you'll see logged * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) — the plan → preview → execute flow each change moves through # Concepts (/docs/ai-console/concepts) The core ideas behind emma AI Console, including how the copilot plans changes, how the diagram stays in sync, and how safety checks keep you in control. # Infrastructure-as-Prompt (/docs/ai-console/concepts/infrastructure-as-prompt) Infrastructure-as-Prompt (IaP) is the idea at the heart of emma AI Console. You express intent in plain language; emma turns that intent into a concrete **plan**, shows you exactly what it will do, executes it only when you confirm, and lets you **export** the result as infrastructure-as-code. Nothing is a black box — every step is something you can read and keep. In a nutshell, every change moves through four stages: * **Generate** — your prompt becomes a plan * **Preview** — you see what will change, where, and what it costs * **Execute** — emma applies the plan, but only after you confirm * **Export** — take the result with you as Terraform, YAML, or JSON The Infrastructure-as-Prompt screen — describe what you want, or start from a template ## Generate [#generate] You describe an outcome, and emma proposes a plan to reach it. You don't specify provider-specific flavor names, API fields, or resource IDs — emma resolves those from your connected accounts and your intent. **Try this** — `Give me a small Ubuntu VM in Frankfurt with a 50GB volume` ## Preview [#preview] Before anything happens, emma shows a preview of the plan: the resources it will create, change, or remove; the provider and region; and an estimated cost. This is where you catch surprises — a bigger instance than you meant, the wrong region — while they're still free to fix. ## Execute [#execute] When the preview looks right, you confirm, and emma applies the plan — streaming progress as it goes. Because execution always waits for that confirmation, IaP is safe to explore: generating and previewing a plan never touches your infrastructure. See [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) for how the gate works. ## Export [#export] Everything you build through emma is real, portable infrastructure. Ask emma to export a single resource or a whole plan and you get clean infrastructure-as-code — **Terraform**, **YAML**, or **JSON** — that you can commit to a repo or hand to another tool. There's no lock-in: the prompt is a faster way to author infrastructure, not a place your infrastructure gets trapped. **Try this** — `Export my Frankfurt VM as Terraform` See [Export to infrastructure-as-code](/docs/ai-console/guides/export-to-iac) for the full walkthrough. ## What's next [#whats-next] * [Deploy an app by chatting](/docs/ai-console/guides/deploy-by-chatting) — IaP in practice * [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) — how execution stays under your control * [The diagram](/docs/ai-console/concepts/the-diagram) — see the result of a plan on the canvas # Safety & confirmations (/docs/ai-console/concepts/safety-and-confirmations) emma is built so that the copilot can be helpful without ever being dangerous. Reading your infrastructure is free and immediate; **changing** it is not. By default, any action that creates, modifies, or deletes a resource is turned into a plan that waits for your explicit confirmation before it runs — and even in the most permissive mode, deletes always ask. In a nutshell: * **Read-only is free** — questions and inspections run without a gate * **Changes are gated** — by default, create / modify / delete waits for your confirm * **The gate is yours** — the copilot cannot approve its own actions * **Permission modes** let you tune how much you're asked (deletes always ask) ## The confirmation gate [#the-confirmation-gate] When you ask for a change, emma doesn't act immediately. It generates a plan, shows you a [preview](/docs/ai-console/concepts/infrastructure-as-prompt#preview) — what will change, where, and the cost — and then waits. Nothing touches your infrastructure until you press **Confirm**. If the preview isn't what you intended, you adjust or walk away, and no change has been made. Confirmation is something only you can give: the gate requires a real human action, so the copilot can't talk its way past it or approve a change on your behalf. ## Read vs. change [#read-vs-change] | Kind of request | Example | Gated? | | --------------- | -------------------------------------------------- | ----------------------- | | Read-only | "What's running?", "Where am I overspending?" | No — runs immediately | | Change | "Create a VM", "Resize this", "Delete that volume" | Yes — waits for Confirm | This split is why exploring with emma is safe: you can ask anything and generate as many plans as you like without risk, because generating and previewing a plan never changes anything. The Plans list — every plan emma generated, with its approval and execution status ## Permission modes [#permission-modes] You choose a permission mode in the chat composer: * **Standard** — emma confirms every destructive action. This is the default, and the safest. * **Autonomous** — emma auto-runs actions without stopping for each one, with one exception: **delete operations always still ask.** Use **Standard** when you want to review each change before it happens. Use **Autonomous** to let emma work through a sequence of steps on its own — accepting that creates and modifications run without a prompt, and only deletes will pause for you. In **Autonomous** mode, create and modify actions run **without** confirmation — only **delete** operations still stop to ask. Choose it only when you're comfortable with that trade-off; stay on **Standard** to approve every change. ## What's next [#whats-next] * [Audit log](/docs/ai-console/concepts/audit-log) — the durable record of every change the gate let through * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) — the plan → preview → execute flow the gate sits in * [The copilot](/docs/ai-console/concepts/the-copilot) — how the copilot proposes changes * [Quickstart](/docs/ai-console/quickstart) — see a confirmation in context # The copilot (/docs/ai-console/concepts/the-copilot) The copilot is how you drive emma. It's a chat assistant that understands your infrastructure: it can answer questions about what's running, reason about cost and security, and carry out changes through [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt). You keep one ongoing conversation rather than hunting through screens. In a nutshell: * It has **context** — it can see the resources in your connected cloud accounts * It works in **conversations** you can return to, with a history of what you've done * It **uses tools** to read and act on your infrastructure, and asks you to confirm anything that changes * You can **choose the model** behind it ## Context [#context] Once you've connected a cloud provider, the copilot can read your resources and answer grounded questions — not generic advice, but answers about *your* environment. **Try this** — `Which of my VMs have a public IP?` ## Conversations [#conversations] Work happens in conversations, listed in the sidebar so you can pick up where you left off. A conversation keeps its context as you go, so you can refine ("make that one bigger", "now do the same in a second region") without re-explaining. ## Tools and actions [#tools-and-actions] Behind the scenes the copilot calls tools to list resources, read cost and security data, and propose changes. Read-only questions are answered directly; anything that would create, change, or delete infrastructure is turned into a plan you must confirm — see [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## Choosing the model [#choosing-the-model] You can pick which model powers the copilot, or let emma route automatically. See [Choosing models](/docs/ai-console/models/choosing-models) for the options. ## Where to find it [#where-to-find-it] Open the copilot from the **emma AI** toggle in the top bar. It docks alongside your work — the diagram, deployments, settings — so you can keep chatting as you move around the console. ## What's next [#whats-next] * [Quickstart](/docs/ai-console/quickstart) — put the copilot to work * [Choosing models](/docs/ai-console/models/choosing-models) — pick the model behind the copilot * [Connect the MCP server](/docs/ai-console/mcp/mcp-server) — use the same capabilities from your own AI tools # InfraMap (/docs/ai-console/concepts/the-diagram) **InfraMap** — the diagram in the left nav — is emma's live picture of your infrastructure. It's built from your real resources across every connected cloud, and it stays in sync as you make changes through the copilot: deploy a VM in chat, and it appears on the canvas. Think of it as the map half of the console, the counterpart to the conversation. In a nutshell: * It reflects your **real resources**, not a hand-drawn diagram * emma **infers the connections** between them for you * It has two views — **Topology** (the graph, with network / compute / security lenses) and **Geo** (a geographic map) * It **stays in sync** with what you do in chat ## Built from your real infrastructure [#built-from-your-real-infrastructure] You don't draw the diagram; emma builds it. It reads the resources in your connected accounts and infers how they relate — which resources sit in which network, what a security group exposes, what's mounted where — so the connections you see reflect how your infrastructure is actually wired. ## Two views: Topology and Geo [#two-views-topology-and-geo] InfraMap has two views, switched at the top of the canvas: **Topology** draws the graph of your resources and their relationships, through three lenses — the same infrastructure tells different stories depending on what you're looking for: * **Network** — subnets, networks, and how traffic can flow between resources * **Compute** — VMs, Kubernetes, and the workloads running on them * **Security** — exposure, rules, and where attention is warranted **Geo** places your resources on a geographic map by region — useful for seeing footprint and residency at a glance. ## In sync with chat [#in-sync-with-chat] Because the diagram is generated from live state, actions you take with the copilot show up here. Ask emma to create, resize, or remove something, and once the change executes the canvas updates to match. Click any node to see its details. InfraMap Topology view — the network lens across AWS, Azure, and GCP ## What's next [#whats-next] * [Quickstart](/docs/ai-console/quickstart) — watch the diagram populate as you deploy * [The copilot](/docs/ai-console/concepts/the-copilot) — the conversation that drives it * [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra) — get your current resources onto the diagram # Integrations (/docs/ai-console/integrations) Connect your cloud providers and the tools your team already uses, including Telegram, Slack, and your observability stack. # Observability integrations (/docs/ai-console/integrations/observability) emma doesn't try to be your observability platform. Instead, it pushes metrics and traces to the tools you already run, through per-vendor adapters. You keep your dashboards where they are; emma feeds them. **Before you start** you need an endpoint and credentials for your observability tool (a Grafana Cloud stack, a Datadog API key, an OTLP collector URL, and so on). ## Supported destinations [#supported-destinations] emma connects through an adapter per vendor, each with the same shape (validate, push metrics, push traces, provision dashboards where supported): | Destination | Sends | | ----------------------------------- | --------------------------------------- | | **Grafana** | metrics, traces, provisioned dashboards | | **Datadog** | metrics, traces | | **New Relic** | metrics, traces | | **Prometheus** | metrics | | **OTLP** (any compatible collector) | metrics, traces | ## 1. Add your destination [#1-add-your-destination] Give emma the endpoint and credentials for your tool. emma validates the connection before saving. **Try this** — `Send my metrics to Grafana` (emma will ask for the endpoint and API token) Credentials for your observability tool are stored to push data on your behalf — provide a key scoped to ingestion, not full account access, where your vendor supports it. ## 2. Confirm data is flowing [#2-confirm-data-is-flowing] Once connected, emma pushes metrics (and traces, where supported) to your destination. Check your own dashboards to confirm data is arriving. ## 3. Provision dashboards [#3-provision-dashboards] For destinations that support it (such as Grafana), emma can provision starter dashboards so you're not building from scratch. **Try this** — `Provision a Grafana dashboard for my infrastructure` ## What's next [#whats-next] * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — alert on the metrics you're now collecting * [Optimize your cloud spend](/docs/ai-console/guides/optimize-cost) — pair cost with your metrics * [The diagram](/docs/ai-console/concepts/the-diagram) — the in-console view of your infrastructure # Cloud providers (/docs/ai-console/integrations/providers) emma is a control plane over the clouds you connect, and one of the providers itself. It manages resources in accounts you own — add a cloud under **Settings → Cloud Providers → Add Provider**, and emma provisions into it and adopts what you already run there — and it can also give you GPU capacity from its own fleet. This page lists the clouds emma supports and what it can do on each. **Connect once, then adopt.** [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra) covers connecting an account and bringing resources emma didn't create under management — evaluation never requires a migration. ## Two ways to get capacity [#two-ways-to-get-capacity] You can get GPU capacity two ways: * **Rent emma's fleet.** emma is itself one of the providers on the platform. Rent GPU capacity emma operates, billed by emma, with no cloud account of your own required. * **Provision into your own accounts.** Run GPUs — and everything else — inside an AWS, GCP, Azure, or other account you already hold, billed by that provider at your own rates. Add a cloud under **Settings → Cloud Providers → Add Provider**. **Which GPU cards you can get depends on the provider and current availability** — emma exposes the cards each provider supports and adds more as they do. emma's own fleet currently includes **L40, A100, H100, H200, B200, and B300**. You always see the exact set available for your provider and region when you pick a configuration, so this page names capability, not a frozen card list. ## The providers emma connects to [#the-providers-emma-connects-to] Available today: * **emma** — rent GPU capacity emma operates directly (see [Two ways to get capacity](#two-ways-to-get-capacity) above). * **Hyperscalers** — Amazon Web Services, Google Cloud, Microsoft Azure. * **Regional & specialist clouds** — DigitalOcean, Gcore, OVHcloud, IONOS, Nebius, Hetzner. * **Private cloud** — VMware — bring emma to infrastructure you run yourself. Coming soon: Alibaba Cloud, Exoscale, Leaseweb, Oracle Cloud (OCI), Scaleway, Vultr. emma fetches the provider catalogue at runtime, so the set you can choose from when adding a cloud always reflects what the platform supports for your account right now. ## What emma can do on each [#what-emma-can-do-on-each] emma provisions and manages the same resource types across the clouds it connects to. **What's available on a given provider, and which GPU cards, depends on that provider** — emma exposes what each supports and adds more over time, and you always see the live set for your provider and region when you pick a configuration. | Capability | What it is | Where | | ----------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | **Compute (VMs)** | instance type, vCPU/RAM, GPU count, HPC shapes, bare metal, driver-ready OS images | connected clouds, per provider | | **GPU** | GPU-backed instances for training and inference; exact cards depend on the provider and availability | connected clouds + emma's fleet | | **Spot** | the same machine, interruptible, at a lower rate | AWS, Google Cloud, Azure | | **Managed Kubernetes** | managed clusters and node groups, created and scaled like any other resource | AWS, Google Cloud, Azure (DigitalOcean and Gcore on request) | | **Block storage** | persistent volumes, snapshots, and backups | per provider | | **Managed databases** | provisioned managed database instances | AWS (RDS Postgres) today | | **Networking** | project networks, subnets, security groups, public IPs | per provider | | **Multi-cloud network** | private connectivity between resources on *different* providers, over emma's backbone | AWS, Azure, Google Cloud instances | | **Direct Connect** | dedicated cross-cloud links, per macro-region (EMEA / AMER / APAC) | AWS, Google Cloud, Azure | ## Regions [#regions] emma provisions into the regions each connected provider exposes; the exact set is read live per provider. **Direct Connect** is enabled per macro-region — **EMEA**, **AMER**, and **APAC** — each with its own real monthly cost you can see before enabling. Where a provider's region sits legally — operating entity, governing jurisdiction, EU-controlled — is not covered here yet. ## What's next [#whats-next] * [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra) — connect a cloud and adopt what's already there * [Self-hosted inference](/docs/ai-console/models/self-hosted-inference) — run models on a GPU you rent or own * [Observability](/docs/ai-console/integrations/observability) — push metrics to your own stack # Connect the Slack app (/docs/ai-console/integrations/slack) Bring emma into Slack and your team gets alerts and infrastructure commands where they already work. This guide installs the app and links it to your emma account. **Before you start** you need an emma account and permission to install apps in your Slack workspace. ## 1. Install the app [#1-install-the-app] Add the emma app to your Slack workspace and authorize it. The console's integrations settings provide the install link and walk you through Slack's authorization screen. Installing grants the app the permissions Slack lists on the authorization screen. Review them, and install only into a workspace you administer or have approval for. ## 2. Link your account [#2-link-your-account] Connect the installed app to your emma account so it knows whose infrastructure to act on. In Slack, run `/emma link` (or follow the prompt from the app's welcome message). Complete the linking step to connect the workspace to your emma account. emma confirms the link. ## 3. Use it [#3-use-it] Once linked, your team can: * **Receive alerts** — route any [alert](/docs/ai-console/guides/set-up-alerts) to a Slack channel * **Run commands** — query infrastructure from a channel or DM **Try this** (in Slack) — `/emma what's running in production?` Responses come back as Slack messages. Read commands run immediately; anything that changes infrastructure still requires confirmation — see [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## What's next [#whats-next] * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — post alerts to Slack * [Connect the Telegram bot](/docs/ai-console/integrations/telegram) — the same, for Telegram * [Observability integrations](/docs/ai-console/integrations/observability) — send metrics to your own tools # Connect the Telegram bot (/docs/ai-console/integrations/telegram) Link Telegram and emma comes with you: alerts arrive as messages, and you can run commands — check what's running, ask about cost — without opening the console. This guide links the bot to your account. **Before you start** you need an emma account. You'll link Telegram to it in the steps below; no bot setup of your own is required. ## 1. Open the Telegram bot [#1-open-the-telegram-bot] Find the emma bot in Telegram and start a chat with it. The console's [integrations settings](/docs/ai-console/concepts/the-copilot) show the exact bot handle and a link to open it directly. ## 2. Link your account [#2-link-your-account] emma needs to know which account the Telegram chat belongs to. Start the linking flow and follow the prompt. Send `/start` to the bot. The bot replies with a linking step — follow it to connect this Telegram chat to your emma account. emma confirms the link. You're connected. Only link a Telegram account you control. A linked chat can receive your alerts and run commands against your infrastructure (read commands run immediately; changes still require confirmation). ## 3. Use it [#3-use-it] Once linked, you can: * **Receive alerts** — route any [alert](/docs/ai-console/guides/set-up-alerts) to Telegram * **Run commands** — ask about your infrastructure right in the chat **Try this** (in Telegram) — `What's running in my account?` ## What's next [#whats-next] * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — send alerts to Telegram * [Connect the Slack app](/docs/ai-console/integrations/slack) — the same, for Slack * [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) — how commands stay gated # Deploy an app by chatting (/docs/ai-console/guides/deploy-by-chatting) The [quickstart](/docs/ai-console/quickstart) creates a single VM. This guide goes a step further: deploying and wiring up a small application — compute plus the pieces it needs — all through the copilot. **Before you start** you need a connected cloud provider. If you haven't connected one, add it under **Settings → Cloud Providers** first. Already set up? Skip to [step 1](#1-describe-the-app). ## 1. Describe the app [#1-describe-the-app] Tell the copilot what you want to run. Describe the shape of the app, not the provider specifics — emma resolves those. **Try this** — `Deploy a Node.js web app with a Postgres database in Frankfurt` emma proposes a [plan](/docs/ai-console/concepts/infrastructure-as-prompt): the compute to run the app, a managed database, and the networking to connect them. ## 2. Review the plan [#2-review-the-plan] Read the preview — the resources emma will create, where, and the estimated cost. Adjust by replying in chat if anything's off ( `use a smaller instance` , `put it in Virginia` ). **Approve the plan** , then **Confirm & deploy** . emma provisions the resources and streams progress. As with any change, nothing is created until you confirm — see [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## 3. Wire it together [#3-wire-it-together] Once the pieces exist, ask emma to connect them — inject the database connection string, open the right ports, attach a domain. **Try this** — `Give the web app the database connection string as an environment variable` ## 4. Check it on the diagram [#4-check-it-on-the-diagram] Open [the diagram](/docs/ai-console/concepts/the-diagram) to see the app, its database, and the network path between them. Click any node for detail, or ask the copilot `Is the web app reachable from the internet?` to confirm the wiring. ## What's next [#whats-next] * [Export to infrastructure-as-code](/docs/ai-console/guides/export-to-iac) — save this app as Terraform, YAML, or JSON * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — get told if the app goes unhealthy * [Optimize your cloud spend](/docs/ai-console/guides/optimize-cost) — right-size it once it's running * [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) — how execution stays under your control # Export to infrastructure-as-code (/docs/ai-console/guides/export-to-iac) Everything you build with emma is real, portable infrastructure. This guide shows how to export it as infrastructure-as-code — so you can commit it, review it, or run it through your own pipeline. There's no lock-in: the prompt is a faster way to author, not a place your infrastructure gets trapped. **Before you start** you need something to export — a resource emma manages, or a plan you've just generated. Any resource on [the diagram](/docs/ai-console/concepts/the-diagram) qualifies. ## 1. Ask emma to export [#1-ask-emma-to-export] Point emma at what you want and name the format. You can export one resource or a whole plan. **Try this** — `Export the web-prod VM as Terraform` emma generates the code inline in the chat, ready to copy. ## 2. Choose a format [#2-choose-a-format] emma supports three output formats — ask for whichever fits your workflow: | Format | Good for | | --------------------- | --------------------------------------- | | **Terraform** (`.tf`) | HCL pipelines, existing Terraform state | | **YAML** | Declarative configs, GitOps | | **JSON** | Programmatic consumption | **Try this** — `Give me that as YAML instead` ## 3. Export a whole plan [#3-export-a-whole-plan] You're not limited to one resource. Ask emma to export everything in a plan — the app you just deployed, say — and you get a single set of files describing the lot. **Try this** — `Export my whole Frankfurt environment as Terraform` ## 4. Run it [#4-run-it] The exported Terraform uses **emma's own Terraform provider**, so you manage the same resources as code. emma includes the usage steps with the export: create a **Service Application** (Settings → Service Applications) for a `client_id` / `client_secret`, save the file as `main.tf` with a `terraform.auto.tfvars`, then run `terraform init / plan / apply`. You get real infrastructure-as-code — version control, review, and CI — for everything you built by chatting. The resources themselves live in your own cloud accounts; the exported config provisions and manages them through emma's provider (YAML and JSON exports are available too). ## What's next [#whats-next] * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) — where export fits in the model * [Deploy an app by chatting](/docs/ai-console/guides/deploy-by-chatting) — build something to export * [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra) — the reverse direction # Import existing infrastructure (/docs/ai-console/guides/import-existing-infra) You don't have to start from scratch. emma can scan your connected cloud accounts, discover what's already running, and bring those resources under management — so the copilot and [the diagram](/docs/ai-console/concepts/the-diagram) reflect your real environment, not just what you built through emma. **Before you start** you need a connected cloud provider. If you haven't connected one, add it under **Settings → Cloud Providers** first. ## 1. Scan an account [#1-scan-an-account] Ask the copilot to look for resources it isn't already tracking. **Try this** — `Scan my AWS account for resources you're not managing yet` emma inventories the account and reports what it found — VMs, volumes, networks, security groups, and more — grouped so you can see the shape of the account. ## 2. Review what was found [#2-review-what-was-found] Look over the discovered resources in the chat and on the diagram as they populate. Narrow the scope if you only want some of it ( `just the resources in eu-central` ). Scanning is read-only — it inspects your account and builds a picture. It doesn't change anything. ## 3. Bring them onto the diagram [#3-bring-them-onto-the-diagram] Once imported, the resources appear in your Inventory and on [the diagram](/docs/ai-console/concepts/the-diagram) alongside anything you built through emma, with the connections between them inferred automatically. From there you can ask about them, optimize them, or export them like any other resource. The Inventory — every resource across your connected clouds, filterable by type, provider, and region **Try this** — `Show me the security exposure of everything you just imported` ## What's next [#whats-next] * [Optimize your cloud spend](/docs/ai-console/guides/optimize-cost) — find savings in what you imported * [Export to infrastructure-as-code](/docs/ai-console/guides/export-to-iac) — codify existing resources * [The diagram](/docs/ai-console/concepts/the-diagram) — explore the imported environment # Guides (/docs/ai-console/guides) Step-by-step walkthroughs for common tasks, including deploying apps, exporting infrastructure as code, and keeping your cloud spend under control. # Manage Kubernetes (/docs/ai-console/guides/manage-kubernetes) emma can work with your Kubernetes clusters the same way it works with the rest of your infrastructure: import a kubeconfig, ask about workloads in plain language, and run `kubectl` through the copilot. Read-only queries run freely; anything that changes the cluster waits for your confirmation. **Before you start** you need a cluster and its kubeconfig. If your cluster is already managed by emma, skip to [step 2](#2-inspect-your-workloads). ## 1. Import a kubeconfig [#1-import-a-kubeconfig] Add your cluster so the copilot can reach it. **Try this** — `Import this kubeconfig` (then paste or attach it) emma registers the cluster and it becomes available to the copilot and the diagram. A kubeconfig grants access to your cluster — import only configs you trust, scoped to the access you intend to give. ## 2. Inspect your workloads [#2-inspect-your-workloads] Ask about the cluster in plain language — no need to remember exact `kubectl` syntax. **Try this** — `Show me the pods in the payments namespace` emma runs the read-only query and summarizes the result, and you can drill in from there (`which of those have restarted recently?`). ## 3. Run kubectl commands [#3-run-kubectl-commands] You can also have emma run `kubectl` for you. Read commands run immediately; anything that mutates the cluster — scaling, deleting, applying — is turned into a change you must confirm. Ask for the action ( `scale the api deployment to 5 replicas` ). Review what emma will run and its effect. Confirm to apply it. Cluster-changing commands are gated like any other infrastructure change — see [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## What's next [#whats-next] * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — get notified about cluster health * [The diagram](/docs/ai-console/concepts/the-diagram) — see clusters and workloads on the canvas * [Export to infrastructure-as-code](/docs/ai-console/guides/export-to-iac) — codify cluster resources # Optimize your cloud spend (/docs/ai-console/guides/optimize-cost) emma can look across every cloud you've connected, point out what you're wasting money on, and suggest cheaper ways to run the same workloads. You review the savings and apply them with a single confirm. **Before you start** you need at least one connected cloud provider with a few days of cost history so emma has something to analyze. Already set up? Skip to [step 1](#1-find-the-waste). ## 1. Find the waste [#1-find-the-waste] Ask the copilot to scan for savings. It runs a waste analysis across your connected accounts and reports back in the chat. **Try this** — `Where am I wasting money right now?` emma lists the culprits — idle VMs, oversized instances, unattached volumes, forgotten spot capacity — each with the monthly cost and why it flagged. Ask a follow-up to narrow it down: `Just the ones over $50/month` or `Only in my AWS account`. ## 2. Compare cheaper options [#2-compare-cheaper-options] Pick something from the list and ask emma to find a better deal. emma compares equivalent options across providers and regions. **Try this** — `Show me cheaper options for the web-prod VM` You'll get a short table of alternatives — a smaller size, a different region, or spot capacity — with the projected monthly saving for each. Savings figures are estimates based on current provider pricing and your recent usage — treat them as a guide, not a guarantee. ## 3. Apply a recommendation [#3-apply-a-recommendation] When you've chosen one, tell emma to make the change. As with any infrastructure change, you get a plan preview first. **Try this** — `Resize web-prod to the option you recommended` Review the plan preview — the change, the impact, and the estimated new cost. Click **Confirm** . emma applies the change and the diagram updates. Changes always wait for your confirm — see [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## What's next [#whats-next] * [Import existing infrastructure](/docs/ai-console/guides/import-existing-infra) — bring in resources emma isn't managing yet * [Set up alerts](/docs/ai-console/guides/set-up-alerts) — get told when spend spikes * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) — how plans, previews, and confirms work # Set up alerts (/docs/ai-console/guides/set-up-alerts) emma can watch your infrastructure and tell you when something needs attention — a VM pegged at high CPU, a spend spike, a security finding. You describe the condition, emma creates the rule, and notifications go to Telegram, Slack, or the console. **Before you start**, decide where you want to be notified. To use Telegram or Slack, link the channel first — see [Connect the Telegram bot](/docs/ai-console/integrations/telegram) or [Connect the Slack app](/docs/ai-console/integrations/slack). You can skip this if you only want in-console alerts. ## 1. Describe the alert [#1-describe-the-alert] Tell the copilot the condition you care about. Describe the outcome — emma works out the metric and threshold. **Try this** — `Alert me if any VM's CPU stays above 90% for 10 minutes` emma proposes an alert rule and shows you what it will watch and when it will fire. ## 2. Choose where it's delivered [#2-choose-where-its-delivered] Pick the channel for this alert. If you've linked Telegram or Slack, route it there; otherwise it appears in the console. Route the alert to Telegram once the bot is linked: **Try this** — `Send this alert to my Telegram` See [Connect the Telegram bot](/docs/ai-console/integrations/telegram) to link it. Route the alert to a Slack channel once the app is installed: **Try this** — `Post this alert to our #ops Slack channel` See [Connect the Slack app](/docs/ai-console/integrations/slack) to set it up. With no channel linked, alerts show up in the console's notifications — nothing extra to set up. ## 3. Confirm the rule [#3-confirm-the-rule] Review the rule — what it watches, the threshold, and the delivery channel. Confirm to activate it. emma starts monitoring and notifies you when the condition is met. ## What's next [#whats-next] * [Connect the Telegram bot](/docs/ai-console/integrations/telegram) — alerts and commands on your phone * [Connect the Slack app](/docs/ai-console/integrations/slack) — alerts and commands in your workspace * [Optimize your cloud spend](/docs/ai-console/guides/optimize-cost) — alert on spend, then act on it # MCP (/docs/ai-console/mcp) Drive emma from your own AI tools by connecting to the MCP server and using its tools directly. # Connect the MCP server (/docs/ai-console/mcp/mcp-server) The emma MCP server exposes your infrastructure to any [Model Context Protocol](https://modelcontextprotocol.io) client — Claude Desktop, Cursor, or an agent you build. It runs locally as a subprocess and speaks to emma on your behalf, so your AI tools get the same grounded view of your clouds that the copilot has. **Before you start** you need an emma access token. Create one in the console under **Settings → API keys**. Node.js (which provides `npx`) must be installed. ## 1. Get the command [#1-get-the-command] The server runs via `npx` — no global install needed: ```bash npx -y @emma/mcp-server ``` It reads your emma token from the `EMMA_TOKEN` environment variable (or a `--token` flag). Keep the token out of shared config where you can. ## 2. Add it to your client [#2-add-it-to-your-client] Register the server with your MCP client. Most clients take a small JSON block naming the command and its environment. Add this to your `claude_desktop_config.json`: ```json { "mcpServers": { "emma": { "command": "npx", "args": ["-y", "@emma/mcp-server"], "env": { "EMMA_TOKEN": "your-emma-token" } } } } ``` Restart Claude Desktop, and the emma tools appear. Add an MCP server in Cursor's settings with the same command (`npx -y @emma/mcp-server`) and set `EMMA_TOKEN` in its environment. Any MCP-compatible client works: point it at the command `npx -y @emma/mcp-server` with `EMMA_TOKEN` set in the environment. Consult your client's docs for where MCP servers are configured. ## 3. Verify the tools [#3-verify-the-tools] Once the client reloads, the emma tools become available. Ask your client something that uses them. **Try this** (in your MCP client) — `List my emma resources in eu-central` The full set of tools, their parameters, and what each one does is in the [MCP tools reference](/docs/ai-console/mcp/tools-reference). Your token scopes everything the server can see and do — treat it like a password, and revoke it in **Settings → API Keys** if it's ever exposed. ## What's next [#whats-next] * [MCP tools reference](/docs/ai-console/mcp/tools-reference) — every tool the server exposes * [The copilot](/docs/ai-console/concepts/the-copilot) — the same capabilities inside the console * [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations) — how changes stay gated # MCP tools reference (/docs/ai-console/mcp/tools-reference) The emma [MCP server](/docs/ai-console/mcp/mcp-server) exposes your infrastructure to any MCP-compatible AI client (Claude Desktop, Cursor, your own agent) as a set of tools. This page lists them by category. Set up the server first — see [Connect the MCP server](/docs/ai-console/mcp/mcp-server). All tools are scoped to the emma account whose token you configured. ## Resources [#resources] ### `list_resources` [#list_resources] Lists the resources in your account, optionally filtered by type, provider, or region. | Parameter | Type | Required | Description | | ---------- | ------ | -------- | -------------------------------------------------- | | `type` | string | no | Filter by resource type (`vm`, `volume`, `k8s`, …) | | `provider` | string | no | Filter by cloud provider | | `region` | string | no | Filter by region | **Effects:** read-only. **Example:** `list_resources(type: "vm", region: "eu-central")` ### `get_resource` [#get_resource] Returns the full detail of a single resource by id. | Parameter | Type | Required | Description | | --------- | ------ | -------- | --------------- | | `id` | string | yes | The resource id | **Effects:** read-only. ## Cost [#cost] ### `get_cost` [#get_cost] Returns cost figures for the account, a provider, or a single resource over a time window. | Parameter | Type | Required | Description | | --------- | ------ | ----------- | ------------------------------------------------- | | `scope` | string | no | `account` (default), `provider`, or `resource` | | `id` | string | conditional | Required when `scope` is `provider` or `resource` | | `period` | string | no | e.g. `last_30d` (default), `mtd` | **Effects:** read-only. ## Security [#security] ### `get_security_findings` [#get_security_findings] Returns open security findings (exposed ports, permissive rules, unencrypted volumes). | Parameter | Type | Required | Description | | ---------- | ------ | -------- | ------------------------------------------- | | `severity` | string | no | Minimum severity: `low` / `medium` / `high` | **Effects:** read-only. ## Global options [#global-options] Every tool accepts these: | Option | Description | | ---------- | ------------------------------------------------------------------------------- | | `--token` | The emma access token (or set `EMMA_TOKEN`) — scopes every call to your account | | `--format` | `json` (default) or `text` | These read tools never mutate infrastructure. Write actions (create/resize/delete) are **not** exposed over MCP without a confirmation flow — see [Safety & confirmations](/docs/ai-console/concepts/safety-and-confirmations). ## See also [#see-also] * [Connect the MCP server](/docs/ai-console/mcp/mcp-server) * [Infrastructure-as-Prompt](/docs/ai-console/concepts/infrastructure-as-prompt) # Bring your own model keys (/docs/ai-console/models/bring-your-own-keys) **Availability** — bring-your-own-keys is part of emma's multi-provider support and is available when it's enabled for your company. If you don't see these settings, ask your emma administrator. You can point emma at your own model-provider accounts instead of using emma's. When you add your own key for a provider, emma uses it for that provider's models — you pay the provider directly with no emma markup, and that provider's models become available to your team. In a nutshell: * Keys are **company-scoped** and managed by an **administrator** * A your-own key **replaces emma's** for that provider and **unlocks its models** * You can also point emma at a **self-hosted, OpenAI-compatible endpoint** * Which models are enabled is controlled **per user** ## 1. Add a provider key (admin) [#1-add-a-provider-key-admin] An administrator adds keys under the company's model settings. Keys are stored encrypted and used only to call that provider on your behalf. Only administrators can add or change provider keys, and keys are shared at the company level — treat them accordingly. Scope each key to what you intend emma to use. ## 2. Point at a self-hosted endpoint (optional) [#2-point-at-a-self-hosted-endpoint-optional] If you run your own OpenAI-compatible endpoint, add it as a base URL plus model id (and an optional key). emma reaches it behind SSRF protections — it must be an `https` URL and cannot target private or metadata-range addresses. For running models on infrastructure emma provisions, see [Self-hosted inference](/docs/ai-console/models/self-hosted-inference). ## 3. Enable models for your team [#3-enable-models-for-your-team] Once a key is in place, its models can be enabled per user. Each person turns on the models they want in their own settings, then selects them in the [model picker](/docs/ai-console/models/choosing-models). Billing note — with your own key, provider usage is billed to you by the provider directly; emma adds no markup on those calls. ## What's next [#whats-next] * [Choosing models](/docs/ai-console/models/choosing-models) — select the models you've unlocked * [Self-hosted inference](/docs/ai-console/models/self-hosted-inference) — run models on your own infrastructure * [The copilot](/docs/ai-console/concepts/the-copilot) — what the models power # Choosing models (/docs/ai-console/models/choosing-models) The copilot is powered by a large language model, and you can choose which one — or let emma pick for you. This page covers the model picker, automatic routing, and per-stage assignment. In a nutshell: * **Pick a model** for the copilot, or leave it on **Auto** * **Auto** lets emma route to an appropriate model for each request * **Per-stage assignment** lets you set different models for different parts of the pipeline ## The model picker [#the-model-picker] Open the model picker in the chat to choose the model behind the copilot. The list shows the chat models your account can access. Your choice applies to the copilot's main reasoning; switch it any time. Which models appear depends on your plan and any [keys your company has added](/docs/ai-console/models/bring-your-own-keys). ## Auto [#auto] Leave the picker on **Auto** and emma runs each request on a suitable model — a top-tier model to orchestrate, a lighter one for the delegated and routine work — so you don't have to think about it. Auto is the default and a good starting point. ## Per-stage assignment [#per-stage-assignment] Under the hood, emma runs a pipeline: an orchestrator that plans, sub-agents that do tool-heavy work, and background tasks like titling and summarizing conversations. You can assign a model to each stage independently — for example, a top-tier model to orchestrate and a lighter one for background work. If a chosen stage model becomes unavailable (a removed key, say), emma falls back to a sensible default for that stage and tells you. ## Which model runs by default, and where your data goes [#which-model-runs-by-default-and-where-your-data-goes] Two questions every security and AI-governance review asks: which model powers the copilot, and where do your prompts and outputs go. * **By default, the copilot runs on Anthropic's Claude models**, through emma's own account. On **Auto**, the orchestrator runs on a top-tier Claude model and the delegated, tool-running, and background work (titling, summarizing) on a lighter Claude model. The model **Auto** pins is Anthropic; if you assign models per stage, individual stages can use another provider where that's enabled for your company. * **Every model call is made by emma's servers** — emma assembles the prompt and sends it. What your own keys or a self-hosted model change is *which model answers*, *whose credentials are used*, and *who pays* — not whether emma handles the request. | How you run it | Where inference happens | Credentials | Billing | | ---------------------------------------------------------------------- | ---------------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------- | | A default emma model | Anthropic's API | emma's | on your emma plan | | [Your own provider keys](/docs/ai-console/models/bring-your-own-keys) | that provider's API | your key, stored encrypted and used only to call that provider | the provider bills you for usage; an emma platform fee may still apply | | [Self-hosted inference](/docs/ai-console/models/self-hosted-inference) | a model server on hardware you run | yours (optional) | you run the hardware | For data residency: self-hosted inference keeps the model and your data on hardware you control, and your own keys keep usage on your own provider account. In both cases emma still composes and sends the request, so the prompt transits emma on its way to the model. Plan a review around **where inference runs and whose credentials are used**, not around emma never seeing the request. Non-Anthropic models and your own keys are available when enabled for your company; the default is Anthropic-only. ## What's next [#whats-next] * [The copilot](/docs/ai-console/concepts/the-copilot) — what the model powers * [Bring your own model keys](/docs/ai-console/models/bring-your-own-keys) — use your own provider accounts * [Self-hosted inference](/docs/ai-console/models/self-hosted-inference) — run models on your own infrastructure # Models (/docs/ai-console/models) Choose which model powers the copilot, bring your own keys, or run inference on your own infrastructure. # Self-hosted inference (/docs/ai-console/models/self-hosted-inference) **Availability** — self-hosted inference is part of emma's multi-provider support and is available when it's enabled for your company. If you don't see these settings, ask your emma administrator. emma can stand up an inference server on your own infrastructure so open models run under your control. It supports two engines — **vLLM** (the default) and **Ollama** — and once a server is running, its model is available like any other in the [model picker](/docs/ai-console/models/choosing-models). In a nutshell: * **vLLM** — the default, higher-throughput engine; pulls models from Hugging Face (needs an HF token) * **Ollama** — the quick-start path; pulls from the Ollama library (no HF token), serves locally * Or **bring an existing endpoint** — point emma at any OpenAI-compatible URL you already run ## 1. Choose an engine [#1-choose-an-engine] Ask emma to set up an inference server and pick the engine that fits. The default. Higher throughput, pulls models from Hugging Face — provide a Hugging Face token for gated or private models. **Try this** — `Set up a vLLM inference server for ` The no-Hugging-Face, quick-start path. Installs Ollama, pulls from the Ollama library, and serves the model locally (not exposed publicly). **Try this** — `Set up an Ollama server for ` ## 2. Let emma provision it [#2-let-emma-provision-it] emma provisions the server on your infrastructure and reports when it's ready. Setup runs synchronously with a time cap; if a matching server for the same engine and model already exists, emma reuses it. A self-hosted model runs on infrastructure you pay for. Size the host to the model, and remember the server keeps running (and costing) until you tear it down. ## 3. Use the model [#3-use-the-model] Once the server is up, select its model in the [model picker](/docs/ai-console/models/choosing-models), or assign it to a pipeline stage. To use an endpoint you manage yourself instead of having emma provision one, add it as an OpenAI-compatible URL — see [Bring your own model keys](/docs/ai-console/models/bring-your-own-keys). ## What's next [#whats-next] * [Choosing models](/docs/ai-console/models/choosing-models) — select your self-hosted model * [Bring your own model keys](/docs/ai-console/models/bring-your-own-keys) — or point at an endpoint you run * [The copilot](/docs/ai-console/concepts/the-copilot) — what the model powers # Backstage Developer Portal (/docs/platform/integrations/backstage-developer-portal) Backstage is an open-source platform which enables organizations to build custom developer portals, giving teams a way to integrate different infrastructure services and software catalogs. One of the most compelling features of Backstage is its ability to integrate modular plugins that extend its functionality in highly customizable ways. We have build plugins for managing and visualizing cloud compute pricing, are particularly powerful for helping your organization take advantage of the best CPU prices in the market. Please see Github page for details: [https://github.com/emma-community/emma-backstage-plugins/ ](https://github.com/emma-community/emma-backstage-plugins/) And follow the [Getting Started Guide](https://github.com/emma-community/emma-backstage-plugins/blob/main/docs/getting-started.md) on installing the emma backstage plugins. # Developer API (/docs/platform/integrations/developer-api) ## What is the API? — FAQ [#what-is-the-api--faq] The REST API is an interface that allows developers and system administrators to programmatically interact with their infrastructure managed through emma. By using the API, you can create, modify, and delete resources, monitor the status of your infrastructure, and automate repetitive tasks. This can greatly enhance the efficiency of your infrastructure management processes. ## API Documentation [#api-documentation] [emma Infrastructure API Documentation](https://api.emma.ms/api/documentations/redoc) ## Getting Started [#getting-started] To start using the API, you will need an API key, which you can obtain from your project. 1. Enter your project, 2. Navigate to **Settings** > **Service Apps**, 3. Create a service application. Select the access level **Read**, **Operate**, or **Manage**, 4. Copy the **Client ID** and **Client Secret** in the service application, 5. Send an API request to the endpoint **/issue-token** as specified in the **Authentication** section of the API documentation. You will receive access and refresh tokens in the response. ## How to Use the Bearer Access Token [#how-to-use-the-bearer-access-token] The Bearer access token is a text string, included in the request header, for example: ```shell curl -X GET https://api.emma.ms/external/v1/locations -H "Authorization: Bearer YOUR_ACCESS_TOKEN_HERE" ``` Once you have the token, include it in the header of your API requests to authenticate and interact with the system. # Integrations (/docs/platform/integrations/emma-api-and-terraform-provider) emma is a turn key cloud management platform for agnostic management of cloud resources from all cloud providers. While we are proud of our first class portal which is applicable for most use-cases, we understand that sometimes integrations into custom systems are needed. Therefore we have an extensive API, a Terraform provider and different plugins for the Backstage developer portal: [Developer API](/docs/platform/integrations/developer-api) [Terraform Provider](/docs/platform/integrations/terraform) [Backstage Developer Portal](/docs/platform/integrations/backstage-developer-portal) # Integrations (/docs/platform/integrations) emma is a turn-key cloud management platform for agnostic management of cloud resources from all cloud providers. While our first-class portal covers most use cases, we understand that sometimes integrations into custom systems are needed — so we offer an extensive API, a Terraform provider, and plugins for the Backstage developer portal. # Terraform Provider (/docs/platform/integrations/terraform) ## Overview [#overview] Terraform is an open-source infrastructure as code (IaC) tool that allows you to define and provision infrastructure using a high-level configuration language. The Terraform provider integrates the capabilities of the API with Terraform, enabling you to manage your infrastructure using Terraform's declarative configuration files. ## What is emma Terraform Provider? — FAQ [#what-is-emma-terraform-provider--faq] emma Terraform provider is a plugin that enables Terraform to interact with emma APIs of various services. It translates the Terraform configuration files into API calls, which create and manage the resources of the project. The emma Terraform provider acts as a bridge between Terraform and the API, allowing you to define your infrastructure as code and manage it efficiently. ## Emma Terraform Provider Documentation [#emma-terraform-provider-documentation] emma Terraform provider documentation: [Terraform Registry](https://registry.terraform.io/providers/emma-community/emma/latest/docs) ## How to Use emma Terraform Provider [#how-to-use-emma-terraform-provider] 1. Get the **Client ID** and **Client Secret** in the service application, as described above. 2. Install Terraform. Download and install Terraform from the official website: [https://developer.hashicorp.com/terraform/install?product\_intent=terraform](https://developer.hashicorp.com/terraform/install?product_intent=terraform) 3. Install emma Terraform provider. To install emma provider, create a folder, and create a **main.tf** file in the folder, copy and paste this code into your file. ```json terraform { required_providers { emma = { source = "emma-community/emma" version = "0.0.1-alpha" } } } provider "emma" { # Configuration options } ``` 1. Open the command line in the folder and run `terraform init`. The provider will be installed. 2. Define Resources. Use the Terraform configuration main.tf file to define the infrastructure resources you want to manage (as described in the provider documentation). 3. Apply Configuration. Open the command line in the folder and run `terraform apply` to provision and manage your infrastructure based on the defined configuration. 4. Enter **client\_id** and **client\_secret** received earlier. # Library (/docs/platform/library) Reusable resources for your projects, including automation templates and ready-to-launch application images. # Library (/docs/platform/library/library) # Company Allocation Optimizer (/docs/platform/my-company/company-allocation-optimizer) ## Overview [#overview] This page allows users to **estimate reallocation options** for products to help optimize cloud expenses. The dashboard provides a visual overview of reallocation opportunities for virtual machines (VMs), detached volumes and on-demand Kubernetes nodes. emma automatically searches for more cost-effective configurations across different cloud providers and locations, identifying the most suitable low-cost options. The chart at the top shows the flow of resources from their current data centers to recommended ones, highlighting potential savings. Beneath the chart, a detailed table lists each resource’s current setup, recommended configuration, location, and cost difference. The dashboard displays only data that users have access to read. For example, a user who is a member of projects A and B but not a member of project C would be able to see only summary information for projects A and B. Allocation optimizer dashboard ## Analytics on this page [#analytics-on-this-page] ### How can I restrict the optimization search by cloud provider or location? - FAQ [#how-can-i-restrict-the-optimization-search-by-cloud-provider-or-location---faq] emma allows you to deploy infrastructure across multiple cloud providers and locations. You can **narrow the scope** of configurations used in the optimization search by setting restrictions for the **cloud provider** and **location**. **Cloud provider restriction** dropdown includes: Any cloud provider, Same cloud provider {/* clickpath */} **Page navigation** — Navigation → Click on ‘Company' → Click on 'Analytics Hub’ → Go to 'Allocation optimizer' and then click on the Cloud provider restriction button Cloud provider restriction control **Location restriction** dropdown includes: Any location, Same location, Same continent, Same area, Same country {/* clickpath */} **Page navigation** — Navigation → Click on 'Company' → Click on 'Analytics Hub’ → Go to 'Allocation optimizer' and then click on the Location restriction button Location restriction control ### How can I filter products? - FAQ [#how-can-i-filter-products---faq] In your company, various products may be created across different projects, services, cloud providers, locations, time periods, etc. This filter allows you to refine and analyze these products by applying multiple conditions and parameters, providing deeper insights into the data displayed on the dashboard {/* clickpath */} **Page navigation** — Navigation → Click on 'Company' → Click on 'Analytics Hub’ → Go to 'Allocation optimizer' and then click on the Filter button **Choose** and **Apply Filters**: * First, select the parameter by which you want to filter data * When selecting "Tag" as Parameter, you will be presented with fields to specify the operator, key, and an optional value * Leave the value field empty to find all products with the specified key, regardless of its value. * Select 'No tag value' for the value field to find only products that have the specified key and an associated value that is empty. * In the field that appears on the right, select the appropriate operator from the dropdown list * Enter the value by which you want to filter or select from the proposed options * Click the “Apply” button to apply selected filters Filter control Applied filters appear in the bars above the chart screenshot To **filter** by **multiple** parameters use one of two ways: * in the “Filter” control, click the “**+ New filter**” button during the filters selecting * click on the button on the right of the existing filter bar To **reset** a filter use one of three ways: * reset a single filter: * in the “Filter” control, click the “**Trash**” icon on the right side of the filter, then click the “**Apply**” button click the “**X**” button on the corresponding plate * reset all filters: * in the “Filter” control, click on the “**Reset**” button, then click the “**Apply**” button # Manage Company Settings (/docs/platform/my-company/general-settings) ## Overview [#overview] {/* clickpath */} **Page navigation** — You can get to this page by clicking on “Company” and then on “Settings” below it. This page shows details of the company which were captured during emma platform registration. You can find the following details depending on your assigned company permission level. You can view your company contact info and registration info in the first two sections of this page. The address details about the company can be found in the third section under “Official address”. This page is not always at this stage, it's empty and ready to be completed at first. It becomes like below image after the initial completing. After the initial completing, further changes of data shown here are allowed only via contacting support at [support@emma.ms](mailto:support@emma.ms?Need%20help%20setting%20up%20company%20general%20settings) Company general settings ### All Company settings [#all-company-settings]