AI
Cloud Asset Inventory
Product News
CloudQuery Platform Adds Business Context and Scheduled Exports to Cloud Inventory
TL;DR
We're rolling out two features for CloudQuery Platform. Apps & Environments groups your cloud resources into apps, environments, and owners automatically, using rules you control. Data Exports lets you schedule Platform data, Cloud Assets, environments, and any query you have permission to run, straight to your warehouse. Apps & Environments is live now on every Platform plan; Data Exports ships today on Enterprise plans.
We're rolling out two features for the Platform that fix two different gaps in cloud asset inventory. The inventory tells you what exists, but not what it's for or who owns it: that's a context gap, and Apps & Environments closes it. The data that could answer those questions stays locked inside the inventory while the teams that need it work out of their own warehouse: that's a delivery gap, and Data Exports closes it.
Both matter more than they used to. More of the questions about your cloud now get answered by an AI agent first, and an agent's answer is only as good as the inventory it reads. A flat, ungrouped inventory is bad grounding data; ask an agent what's running in production and it has to guess. Underneath the feature names, both of these are about giving agents, and the humans who still double-check them, something solid to stand on.
Apps & Environments: Giving Resources Business Context #
Ask an AI agent "what applications are running in production" today and it has to guess where to look. It grabs at tag keys that look promising, account names that sound like prod, and often lands on a different answer tomorrow. That's because asset inventories are usually a flat list of resources with no built-in sense of ownership or purpose.
We built a new inventory view that groups resources automatically into "apps," a service or business unit, each with an associated environment and owner, based on rules you control:
- Tags (default): a tag key like
serviceorappsupplies the app name. Stack multiple tag rules to work around inconsistent tag hygiene: mixed casing, missing tags on some resources. - Account name pattern: a regex extracts the app name from an AWS account naming convention.
- env0 project/environment mapping: uses the existing link between a resource and its env0 project or environment to assign the app or environment name.
- Tag-neighbor propagation: resources connected through CloudQuery's relationship graph inherit an app/environment assignment even when they aren't tagged themselves. In the demo below, an API Gateway route inherits its service tag from the API it's attached to, which covers resources that can't carry tags or were created by hand and linked in after the fact.
The same rule types (tags, name pattern, project/environment) apply separately to environment classification, and you set the priority order they're evaluated in.
Once synced into env0, this classification splits resources into managed (tagged, IaC-covered) and unmanaged (connected but not explicitly owned). New SQL console tables expose apps and environments directly, and the built-in AI assistant now treats them as first-class concepts, so it answers ownership and environment questions the same way every time instead of guessing. We're planning more rule types, ServiceNow and a dynamic SQL rule, based on customer feedback.
Flexera's 2026 State of the Cloud Report surveyed 753 IT and cloud professionals and found wasted cloud spend climbed to 29% last year, the first increase in five years, even as FinOps team adoption reached 63%. Their own explanation for the gap: most organizations still lack a continuously current record of what's running across their hybrid, multi-cloud estate. That's the gap Apps & Environments is built to close.
Before: ask the AI assistant "what applications are running in production" and it infers an answer from whatever heuristic it lands on that session. Ask again tomorrow, or have a colleague ask, and the list may not match.
After: the same question resolves against the app and environment rules you defined once. The assistant returns the exact set of apps whose environment equals production, owners attached, every time.
Data Exports: Getting Normalized Data Out on a Schedule #
We've heard this one a lot: you can already ship raw source data to a destination like Snowflake, or pull CloudQuery's processed tables (Cloud Assets, environments, and so on) through the platform API. Getting those processed tables into another system meant writing a script to run the same SQL query on a loop and page through results. That's extra engineering work, and it puts repeated load on our database.
Data Exports is a scheduled export you set up from the SQL console or a dedicated Data Exports page:
- Query: any query the requesting user has permission to run. Access controls carry over, so you can't export data you couldn't otherwise see.
- Format: JSONL, CSV, or Parquet.
- Schedule: daily, weekly, monthly, or a custom cron expression. You can also trigger it manually.
- Delivery: each run produces a file plus a ready-to-copy curl command, so a script or pipeline can pull the latest export directly instead of someone downloading it by hand. Earlier versions stay available through the API, and files are retained for 14 days before deletion.
Data Exports is available on Enterprise plans.
Retool's State of Internal Tools survey found developers spend more than 30% of their time building internal applications like dashboards and one-off exports, climbing to 45% at companies with 5,000+ employees. A follow-up survey of 2,276 developers found 86% say that investment held steady or grew the following year. Every custom export script pointed at an API is a piece of that tax, and Data Exports is built to remove it.
An Example Use Case #
Picture a platform team at a mid-size SaaS company: a dozen-odd services spread across AWS and GCP, three environments each. Nobody disputes that tagging matters, but coverage is spotty enough, in the way it typically is at this scale, that basic ownership questions don't have a reliable answer.
So the team built what most teams build: an internal dashboard joining tags, account IDs, and a spreadsheet of tribal knowledge about who owns what, maintained by whoever remembers to update it when a service gets renamed or a new account shows up. To get that data in front of finance and security without handing out console access, someone wrote a script that hits the API on a cron job, pages through results, and drops a CSV somewhere.
Apps & Environments replaces the dashboard: define the rules once, tags first, account-name pattern as a fallback, tag-neighbor propagation to catch what's connected but untagged, and the grouping keeps itself current. Data Exports replaces the script: the same Cloud Assets view, scheduled, landing in the warehouse finance and security already query, with no pagination logic left for anyone to maintain.
Try It #
Apps & Environments is live now on every CloudQuery Platform plan, no enablement needed. Data Exports is available today on Enterprise plans. Book a demo to see either running against your own inventory, or head to the platform documentation to set up your first export or rule set.
Frequently Asked Questions #
Do I need to set up anything before the AI assistant can use apps and environments? #
No extra setup beyond defining your rules. Once you configure tag, account-name, or project rules, the AI assistant treats apps and environments as first-class concepts automatically.
Can I use Apps & Environments and Data Exports if I'm not on an Enterprise plan? #
Apps & Environments is available on every Platform plan. Data Exports is Enterprise-only for now.
What happens to my resources if I change a rule after Apps & Environments is already running? #
Reclassification runs against the new rule set on the next sync, so resources move to their new app or environment grouping automatically. Nothing needs a manual re-tag.
Can a Data Export include raw source data, not just processed tables like Cloud Assets? #
A Data Export runs whatever SQL query you have permission to run, so it can pull raw source tables too, not only the processed Cloud Assets and environment tables described above.
What happens to old Data Export files? #
Each run produces a new file, and earlier versions stay available through the API. Files are retained for 14 days before deletion.
Does a Data Export respect the same access controls as the SQL console? #
Yes. Access controls carry over from the requesting user, so you can't export data through a Data Export that you couldn't already see in the SQL console.
