Repository navigation
docs: stop documenting workload deployment, and break up the Azion Lib Applications page - #2490
Merged
Merged
Conversation
The workload deployment endpoint is omitted from the published API v4 reference, and the model it was built for, several deployments per workload, was never implemented in the Console. The CLI commands were written when that model looked practical and were never removed, so the reference page documented a surface the product does not support. The page goes in both languages, with a redirect to the CLI workload page, its row in the CLI nav tree, its row in the resources table, and the three intros and Related items that routed a task to it. Those now name the Console field that holds the binding, and the `deployments` entry of `azion.config.js` for a project that deploys. The CLI glossary keeps the term, since `azion deploy` prints it and `azion.config.js` carries the key, and defines it as what the deploy writes from that key.
The command was still taught on 42 English pages and their Portuguese pairs as the way to bind an application, a firewall, or a custom page set to a workload: the marketplace integration guides, the migration guides, the CLI panels of the quickstarts, and the reference pages for Workloads, Applications, Firewall, and Custom Pages. Each one now routes the binding to Azion Console, the interface that manages it: Workloads, the workload, then the Application, Firewall, or Custom Page field of Deployment Settings. The CLI panels add the route a project does have, the `deployments` entry of `azion.config.js` that `azion deploy` writes. The API panel of the Workloads quickstart sent readers to its CLI panel, which now sends them to the Console, so it names the Console panel instead. The Workload settings reference drops the CLI flag column of its deployment table, along with the four rows whose only interface was that column, and keeps the three Console controls its text already describes. Terraform keeps `azion_workload_deployment`, the MCP tools keep theirs, and the azion.config.js and azion-lib references keep the manifest key: each is a public surface that still works.
…esource The Applications page carried 2010 lines in each language: 35 function sections, 17 type sections, and the material that frames them. A reader looking for one function scrolled past six resources to reach it. The page keeps its permalink and now holds what every function shares: the install block, Authentication, Response envelope, Errors, and a directory of the seven pages that follow, with each function linked to its own section. The functions move to one page per resource, and the types to a page of their own. Application methods goes to the Application page, since the methods hang off the object getApplication returns rather than off any one sub-resource. Two headings slugged identically, `createAzionApplicationClient` the function and `CreateAzionApplicationClient` the type, so in one page the second answered to `-1` and every link pointed at the first. The split maps each anchor as the single page resolved it, then rewrites it to the anchor its target carries on its new page. The sidebar caps a tree at three levels, and Application already sat at the third. Dropping the Reference wrapper promotes Product APIs, Function helpers and Configuration and types to the top level, which leaves Application at the second and its seven pages at the third. The azion-lib overview links each new page, and the troubleshooting pointer for createOrigin and createCacheSetting now reaches them directly. Applies to 7 new English pages and their Portuguese pairs.
marcus-souza-azion
requested review from
a team,
bruno-andrade-azion,
isaque-bock-azion and
pedro-ribeiro-azion
as code owners
October 15, 2026 17:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
**Related issue:**MM-16146 — two independent pieces of work. The first comes from internal review of the CLI pages: the workload deployment endpoint is omitted from the published API v4 reference, the model it was built for was never implemented in the Console, and the CLI commands written for that model were never removed. The second is a page that outgrew itself.
Pages affected: 116 content pages plus the CLI nav tree, the Azion Lib nav tree, and two redirect data files — 120 files. Of the content pages, 100 are edited, 14 are new, and 2 are deleted.
Type of change
feat)fix) — typo, broken link, wrong informationdocs) — rewrite, expansion, upkeepi18n)refactor/chore) — reviewed by UXE, no content mixed inAuthor checklist
type(scope): summary(see GOVERNANCE.md §4)title,description,meta_tags,namespace,permalink,last_reviewedpt-brupdated in this PR or follow-upi18nissue createdpnpm build:local(build + frontmatter check) without errors