Deployment

The Deployment page plans how your project runs at the volume you expect: where it runs, what it needs, what a page costs, and how many documents people still verify. It looks ahead; the other pages cover the rest: Evaluation measures how well the draft works, Reporting shows the real straight-through processing, throughput and cost of a live project, and Publish is in the title bar. Three folded groups at the top are what you plan for (Your Project, Your Plan, Deployment Options, which also holds the chosen way's architecture and details); under them, Your Deployment Plan gives the result, and the plan can be printed or sent to sales. While the page recalculates after a change, Calculating... shows beside Print in the title bar. Folded, the page fits on one screen. What you set (volume, documents, plan, the way of running it, its settings, and which groups are open) is kept in this browser for you and this project, so it is still there when you come back. The ways of running it:

• SaaS: our cloud; nothing for you to run.
• SaaS with your own models: our cloud, using model and OCR deployments in your subscription.
• Managed in Azure: DocAI Fabric deployed in your Azure subscription; we deliver the updates, watch the logs and fix errors (overview).
• On premises: you run DocAI Fabric and open-weight models on your own servers (self-hosted).

The page is in beta (early access), and a band under its title says so: treat its figures as a first estimate and check them before you commit to hardware or a budget.

Open it from Design > Deployment. It needs the Configure project permission, the same as Evaluation, because it reads the project's evaluation runs and transactions. It only reads: planning spends no tokens.

Estimates, not quotes

Every figure is an estimate from a sample. Our plan is included at the pay-as-you-go price unless you enter an annual commitment price; for annual commitment pricing, contact sales.

Your project

The estimate always runs this project's workflow: its steps, the model each step uses and its OCR engine, taken from the workflow's configuration. What you choose is the documents it is measured on, under Documents:

Documents	What it reads	When to use it
Evaluation run	The latest finished run of an evaluation dataset	The best choice: it also carries the run's accuracy, shown next to the cost
Playground	The completed Playground transactions of the newest configuration	While you set the project up; process a representative sample first
Production	The most recent completed transactions of the published version	Once the project is live
Typical documents, assumed	The kind of document and the pages per document you choose	Only before the project has processed anything

Processed documents give the real tokens, OCR pages and time per page; assumed ones give a ballpark. A step's time is its typical run (the median, from 3 runs on): a run that took more than five times as long, most likely waiting on the model service, is left out, and the Per-page profile says so. Time per page sets how many application replicas the volume needs. A new project has processed nothing, so the page opens on assumed documents and asks you to measure first: upload 10 or more typical documents in the Playground, or add them to an evaluation dataset and run it, let them finish, and come back. The plan picks them up automatically, and says which workflow version and how many pages it measured. When you change the workflow after the documents ran (switch a step off, set OCR to none, choose another model or engine), the plan applies the change to the measured figures and lists it; process documents again to measure the new workflow itself. The Documents choice says how many processed transactions ran on the current draft.

It counts one pass of each transaction's run, so testing does not inflate it: re-running a whole transaction starts its count again, and documents re-run one at a time in the viewer are not added. Transactions processed before usage was recorded are skipped. Conversion happens at import, outside the workflow, so its time is an assumption: the profile's Import step, marked assumed. A small sample gives a soft figure: below 50 pages or 10 transactions the page says so beside Documents, recommends processing at least 10 typical documents (50 pages or more), and links to where to add them.

Enter the volume as Pages per day, month or year. The plan spreads it evenly over the period. Count pages, not documents: OCR and tokens grow with pages. The plan updates as you change any input.

Settings taken from this project (folded under the inputs) lists what else the plan reads from the project, each with a link to where it is changed:

• the workflow's model steps, in workflow order, and the model or OCR engine of each. A step the measured documents did not call a model for is listed too, with the reason. An Extract that Classify did inside its own call is measured there. An Agent Review with nothing to review, or a skipped step, is not in the plan: measure on documents that exercise it;
• data retention: how long production transactions are kept, from Workflow settings (Data retention). Storage is paid by volume, so the plan sizes it from this period: 60 days when the project has not set one, a day when completed transactions are deleted at once, and 12 months when they are never deleted.

The currency is the platform's, the one model costs use.

Your plan

One plan for the project, whatever runs it:

• Pay as you go: our price per 1,000 pages, the same whatever runs it, filled in for you: the price the platform administrator set for your currency, else our price list.
• Annual commitment: the price you agreed with sales for a yearly volume; enter it per 1,000 pages.
• Infrastructure only: no plan (0), to see what running it costs.

Every price on the page is per 1,000 pages.

Annual commitments come with volume-based discounts: Contact sales for a quote. The plan is in your platform currency, the one set for model costs on the Models page; the price list covers US dollars, euros and Australian dollars, and in any other currency the administrator sets a price or you choose Annual commitment and enter yours.

Deployment options

The tiles are the four ways of running it, on every installation. The one this installation runs is marked and recommended, and the page opens on it; the others are for reference. Each leads with what running it costs per 1,000 pages, our plan left out, with the monthly total under it. Under the tiles, the chosen way's settings. Under the settings, Architecture and Details, folded, belong to the chosen way.

In every way but SaaS, each model in the picture has Model for these steps, and the choice is the same in all three. Rented by the token: keep the workflow's model, or choose another connected to the platform or to your organisation; you pay its token prices (enter yours in Components). A platform model needs a quota in your subscription: enter the quota you have (Your quota, tokens a minute) and the plan checks it covers the volume, summed over the workflow steps that use the same model. Your organisation's models are checked on their measured capacity instead, on premises too. Self-hosted: an open-weight model (Qwen, Gemma) without connecting anything, on GPUs the plan recommends and counts; in Components, the Model servers row lets you choose another GPU and takes the monthly cost of a GPU server instead of token prices (in Managed in Azure the servers take Azure's list price). Your organisation's models are measured from this page (Measure its real capacity); the platform's models by your system administrator. Its picture, under Architecture, shows who runs what (our cloud, your subscription, your data centre) and each service with the size the plan gave it.

SaaS with your own models

Every model the project's workflow uses becomes one you provide, listed with the steps that use it and the throughput it must sustain. By default you provide the same model in your own subscription: the plan gives the tokens-per-minute quota to request and prices its tokens at that model's rate.

To use a model of your own instead, choose it under Provided model. The plan then checks it against its latest measurement from Models > Performance (Testing and Measuring Models) and prices it at the rate set on the Models page. Tokens were measured with the project's current models, so a replacement may use more or fewer: run Evaluation with it connected to compare accuracy and cost. Choosing one of your models needs the Manage models permission.

Managed in Azure

Choose the Layout, the level of protection (Architecture and Azure Services):

Layout	What the picture adds
Single zone (test, development)	One availability zone; the lowest cost
Zone-redundant	The application spread over three availability zones, zone-redundant queue and storage
Geo-redundant: recovery	A copy of your documents and the model and OCR accounts in a second region
Geo-redundant: warm standby	A running second environment in the second region, ready to take over

Each part of the picture names the Azure service it is: Azure Container Apps, Azure Managed Redis (the queue), Azure Blob Storage (with the volume your documents take up over the retention period), Azure AI Services (the models) and Azure AI Document Intelligence (OCR). Below them are the services with nothing to size (Key Vault, Container Registry, logs and alerts), and hovering any of them, or the private endpoints, says what it is for.

Models are deployments in your subscription: the plan gives the quota to request per model. Each plan is one deployment: plan a test or development deployment on its own, with Single zone and its own volume.

On premises

Choose the Layout (Self-Hosted):

Layout	What it is
Standalone (test, development)	One machine with Docker Compose: the application and Redis containers, documents in a local folder. The plan sizes that machine and says when the volume needs more than one
Multi-node (high availability)	A K3s or Kubernetes cluster of two or more application nodes behind a load balancer, with a shared Redis and S3-compatible object storage; it keeps running if a node fails

The cloud models the project uses are not available on premises, so each is replaced by an open-weight model you run on GPUs, chosen under Model for these steps. The plan recommends the GPU: the smallest that fits each replacement on one server and carries the volume on at most 8 GPUs (the largest when none does). It states what the volume needs: the GPUs per model, the vCPU and RAM of the application, and the storage. Choose another GPU on the Model servers row in Components if you have one; the recommendation stays in the list. A model that does not fit in one GPU's memory gets several GPUs per copy.

Throughput is marked Measured where we measured that model on that GPU, and Estimate otherwise (from typical figures for that GPU); measure the model you deploy with Models > Performance for a real figure. The accuracy of a replacement on your documents is not known until you run Evaluation with it connected, so do that before deciding. Cloud OCR is replaced by the built-in engine, which runs on the application nodes.

Enter the monthly cost of a model server and an application node in Components, beside their lines, to price the hardware; until then the option says its hardware is not priced. The plan counts servers of 2 GPUs and application nodes of 16 vCPU and 64 GiB; enter your own sizes on those rows in Components (GPUs per server, vCPU and GiB RAM), and empty a field to go back to the plan's.

Your deployment plan

Three cards, for the volume, plan and deployment option chosen in the groups above:

• Expected STP (straight-through processing): an estimate of the share of documents no one has to verify, and, in the period of your volume, how many documents are left to verify. It comes from an evaluation run first (the one you measure on, or the latest), since that runs the configuration you are designing while Production may run another version: the documents whose class and every field match ground truth. Without an evaluation run, it is the share of the measured documents Human Review let through (no person decided it). When the measured documents are Production's, where review time is recorded, it adds the hours of review and the people full time that takes (8 hours a day, 168 a month). Nothing measured yet: run an evaluation. The real rate of a live project is in Reporting.
• Required Capacity: the pages an hour to carry, then what the resources must sustain: with SaaS the model tokens a minute, which our shared service carries; with the other ways, which you provide, each model's tokens a minute, the OCR's requests a second and the application's replicas; on premises, the GPUs per model, the application's vCPU and RAM, and the storage, with the GPU the plan recommends. Whether they can is known only for the way this installation runs projects, so only there does the card say when it cannot (above what the shared service gives one customer: contact us).
• Cost per 1,000 Pages: what 1,000 pages cost all in, and per month: our plan and the cost of running it.

The chosen way's picture (Architecture), its parts and costs (Components) and the Per-page profile are in Deployment Options, under its settings.

Print or request it

The page ends in the plan's own actions:

• Print the plan, or save it as a PDF from the print dialog, to share it.
• Request this deployment, for a way of running it this installation does not run: the print dialog opens, where you save the plan as a PDF, then an email to sales with the main figures filled in; attach the PDF and send it. Meanwhile you can publish from the title bar and run the project in our cloud.
• Send this plan to sales, on an installation in your own Azure or on your own servers, to plan growth with us.

Read the components

Components, in Deployment Options, is one table of everything the chosen way needs, folded with its monthly total showing. Costs here leave out our plan. One row per part (a model, the OCR service, the application, the queue, the storage, the model servers):

• Size: how many and of what size, for example 76 replicas of 2 vCPU and 4 GiB, or 6 × H100.
• Needs: what it must carry for your volume: tokens a minute for a model, requests a second for OCR, replicas or vCPU and RAM for the application.
• Capacity: what is there against it and whether it is enough, shown only for the way this installation runs. For any other way the table states what is needed: your subscription or servers are not visible from here. A quota you enter and your own models' measurements are checked in every way, under Needs. For one of your organisation's models, Measure its real capacity (here, or in the hint under the model in Architecture) runs its performance measurement from this page, the same as Models > Performance, and the plan uses the result when it finishes. A model connected to the platform is measured by your system administrator; an open-weight model shows an estimate until you connect and measure it.
• On premises and in Azure everything is yours. With SaaS and your own models, only what you provide is listed; SaaS lists what our service must carry, with no costs, since the plan is the price.
• Per month: the part's cost lines, each with its quantity, unit price and monthly cost. Model and OCR rates come from the Models page (Cost and Budgets); Azure prices are dated US list prices, which your agreement may change. Every price is a field you can change to yours, in the unit shown: a price the plan does not know (a model's token price, the OCR price per 1,000 pages, a GPU server or application node a month) is an empty amber field, and an Azure price shows the list price until you replace it (Container Apps' replicas take one price per replica-hour, active or idle); GPU virtual machines for an open-weight model are priced per GPU-hour at Azure's list price (A100 or H100, the GPUs Azure offers). Empty a field to go back to the plan's price. Application replicas come in two lines: (active) while they process documents, at Azure's active rate, and (idle) while they wait, at a much lower one; a warm standby only waits, with a queue the size of production's so it can take over without a manual step. Prices are kept for this project in this browser. A line without a price is left out of the total, which says so.
• Document storage, in Azure, follows the layout: locally redundant (LRS) in a single zone, zone-redundant (ZRS) otherwise, and with a geo-redundant layout the copy in the second region and the transfer to it are part of its cost. OCR shows the requests a second it must take; above the standard tier's 15, request a higher limit for your OCR service.

Under the table are the notes: what to request, what the figures assume.

Per-page profile is what the plan rests on: per step, in workflow order, the model, tokens, OCR pages and seconds of one page, and the model and OCR cost per 1,000 pages. With SaaS a step's cost is part of the plan, and on premises it runs on your servers. The last row adds what the way you run it costs per page on top of every step (the application, queue, storage and servers), and the total is what running it costs per 1,000 pages.

With Managed in Azure the plan also answers how many application replicas the volume needs, and sets the deployment's maximum from it (never below the template's 10).

Print it

Print the plan, or Print in the title bar, produces the plan for the option you are looking at: the cards, its picture, the components and the profile, unfolded. Choose Save as PDF in the print dialog to keep a file.

Ask the assistant

The assistant answers the same question in a conversation ("could we run this on premises at 2 million pages a month, and on what hardware?") from the same plan, and can open this page for you.

Without a project

The Capacity Calculator in the deployment documentation sizes a volume from manual assumptions, without signing in. It covers capacity only; the delivery options, architecture and cost need a project.