Large Workloads

Last updated: May 11, 2026

Most integrations should start on a self-serve plan. Use this page when your workload is close to the limits or depends on larger image, grid, or delivery behavior.

Start self-serve when

Starter or Growth is the right path when the workload fits the published plan limits and the service can process jobs through the normal shared queue.

Good self-serve shapes include:

• product thumbnails and responsive image variants
• ordinary optimization and format conversion
• tile generation within the published tile cap
• grid_render jobs within the plan megapixel limit
• immediate tile_patch updates inside the patch count and patch area limits
• short-lived artifact retrieval through signed download URLs

Contact before launch when

Use the contact path before committing production traffic when the workload needs:

• source uploads beyond the Growth limit
• outputs beyond the Growth size or edge limits
• grid renders beyond the Growth 100 MP limit
• full grid or tile rebuilds that happen in bursts
• multi-region or frequent tile_patch updates
• dedicated worker scheduling or a reserved processing lane
• longer retention for derived outputs
• CDN-backed hosted delivery
• a migration or backfill that could consume a large monthly credit pool quickly

The goal is to test capacity before the workload becomes user-facing.

Shared-service guardrails

ImageGrid uses hard limits alongside monthly processing credits. Credits answer "how much can this account process this month." Limits answer "what size of job can the shared service handle predictably."

Expect enforcement around:

• upload bytes
• input and output megapixels
• input and output edge pixels
• generated tile counts
• grid render megapixels
• tile patch area and patch count
• artifact size and retention windows
• request-rate limits

Having credits available does not bypass these limits.

Client behavior for larger runs

For larger batches:

• throttle your own workers instead of sending all jobs at once
• respect 429 and Retry-After
• spread rebuilds over time when they are not urgent
• store job IDs and artifact IDs so failed batches can resume precisely
• poll with backoff instead of fixed fast polling
• run one representative batch in preview before scaling the run

If a batch is commercially important, contact ImageGrid with representative source sizes, target outputs, expected monthly volume, burst pattern, and launch date.