Overview

Press.js Cloud is a hosted platform that renders your web documents into PDFs. You upload your built web app, we run headless Chromium with Playwright to paginate and export it, and you get back a PDF — no servers, no browser automation, no infrastructure to manage.

How it works

Build ──► Upload ──► Render ──► Download

1. Build your document as a web app using Press.js layout primitives
2. Upload the built artifacts (HTML, CSS, JS, assets) to Press.js Cloud as a deploy
3. Render — Press.js Cloud launches headless Chromium, loads your document, paginates it, and exports a PDF. Rendering is asynchronous: submit a job and poll or get notified when it completes.
4. Download the resulting PDF, or manage it through the platform (aliases, version history, access control)

Core concepts

Press.js Cloud is organized around a single fundamental unit: the deploy. Every document you create, every version you upload, every render job you run, every environment variable you set — they all live inside a deploy. Understanding this model is the key to working effectively with Press.js Cloud.

Deploy

A deploy is the top-level container for your document. Think of it as the “project” or “workspace” that holds everything related to a single PDF-generating application.

Each deploy has two identifiers:

Identifier	Example	Description
Deploy ID	dpl_abc123	Unique, immutable machine identifier. Use in API calls and scripts.
Slug	my-report	Human-readable string you choose. Unique within your account, can be renamed.

A deploy starts as an empty shell — lightweight to create. You add versions, run render jobs, and configure settings as you go.

What’s scoped to a deploy

Everything below lives at the deploy level. Creating a new deploy means a fresh namespace for all of these:

Resource	Scope	Notes
Versions	Per-deploy	Each deploy has its own linear version history
Render jobs	Per-deploy	Jobs always target a specific deploy + version
Aliases	Per-deploy	production, staging, etc. are namespaced per-deploy
Environment variables	Per-deploy	Key-value pairs available at render time
Secrets	Per-deploy	Encrypted, write-only values for API keys and tokens
Fonts	Per-deploy	Self-hosted font files bundled with your uploads
Render timeout	Per-deploy	Configurable default, overridable per render job

Limits like files per commit and bytes per commit are also enforced at the deploy level. See Plan Limits for details.

Version

Versions are immutable snapshots of your uploaded artifacts. Every time you upload new or changed files, Press.js Cloud creates a new version. Versions are content-addressed — only changed files are transferred and stored, so subsequent deploys are fast and storage-efficient.

Key properties:

• Immutable — once created, a version cannot be changed
• Linear history — versions form a chronological sequence within a deploy
• Independently renderable — any past version can be rendered at any time, making rollback trivial

Alias

Aliases are mutable pointers that let you assign stable names to specific versions. They decouple “which version to render” from “which version was most recently uploaded.”

production  → version #3   (what end users see)
staging     → version #4   (testing before release)
latest      → auto-updates to the most recent version

Aliases are per-deploy and can be reassigned at any time. In-flight render jobs are unaffected by alias changes — they continue using the version they were created against.

Render job

A render job is a single execution of your document in headless Chromium to produce a PDF. Each render job:

• Targets a specific deploy and version (or alias)
• Optionally accepts payload data for per-job customization
• Produces exactly one PDF output
• Runs asynchronously — submit, then poll or use webhooks for completion notifications

Putting it together

Deploy: my-report
├── Environment variables
├── Secrets
├── Fonts
├── Version #1 ──── render job → PDF
├── Version #2 ──── render job → PDF
│   ├── alias: production
├── Version #3 ──── render job → PDF
│   ├── alias: staging
│   ├── alias: latest

A single deploy holds multiple versions, each version can produce multiple render jobs, and aliases let you route consumers without updating downstream URLs.

When to create a new deploy vs. a new version

Scenario	Do this
A new document or project	Create a new deploy
Updated content, styles, or assets for an existing doc	Push a new version
A completely different document type or layout	Create a new deploy
Environment-specific configuration changes	Update deploy settings
Testing a new layout before promoting to production	Push a new version + use a staging alias

A useful rule of thumb: new deploy = new document identity. New version = update to an existing document.

Interfaces

Press.js Cloud is accessible through three interfaces — all backed by the same API.

Interface	Best for
Web Dashboard (cloud.pressjs.dev)	Manual uploads, quick tests, browsing render results, managing settings
CLI (press)	Local development, CI/CD pipelines, repeatable deployments from the terminal
REST API (docs)	Custom integrations, scripted workflows, fine-grained control over every operation

The web dashboard is the fastest way to get started. The CLI and API are designed for automation — both support API key authentication so you never need a browser.

CLI at a glance

The Press.js Cloud CLI is a native Rust binary distributed through the press CLI or as a standalone download.

press install cloud   # install or upgrade the cloud CLI
press login           # authenticate via OAuth or API key
press deploy          # build and upload in one command

Key capabilities:

• Content-addressed uploads — SHA-256 deduplication means only changed files are transferred on subsequent deploys
• Flexible auth — OAuth device flow for local development, API keys (PRESS_CLOUD_TOKEN) for CI/CD
• Deploy management — create deploys, push versions, manage aliases, and roll back from the command line
• Zero runtime dependencies — a single static binary, ideal for Docker and CI environments

See the CLI documentation for install instructions, command reference, and CI/CD integration guides.

REST API at a glance

Every action available in the dashboard and CLI is also available through the REST API.

Base URL: https://api.pressjs.dev/v1
Auth:     Bearer pcak_xxxxx

The API covers four workflows:

• Deploy — create and manage deploys, versions, and aliases
• Upload — upload artifacts through resumable upload sessions
• Render — create render jobs, poll status, pass payload data
• PDF — download rendered PDFs, manage output retention

All endpoints use cursor pagination for lists, idempotency keys for safe retries, and a uniform JSON error format. See the REST API overview for authentication, headers, pagination, and the full endpoint reference.

Runtime configuration

Press.js Cloud injects dynamic data into your document at render time through the p.press.internal origin. This lets you reuse the same deploy for many different outputs:

• Payload — per-job JSON or binary data that is available only during that render. Use it for invoices, reports, certificates, or any document where content changes between renders.
• Environment variables — per-deploy key-value pairs for non-sensitive configuration like API base URLs or feature flags.
• Secrets — per-deploy, write-only, encrypted values for API keys, tokens, and passwords.

A pressCloud global is injected into your page for ergonomic access to these values. Call pressCloud.revokeDataAccess() after reading sensitive data to lock it down before rendering untrusted content.

Fonts on Cloud

Press.js Cloud renderers run headless Chromium on Linux. System fonts are not guaranteed — self-host your fonts bundled with your deploy artifacts. Free plan renderers have no external network access, so CDN fonts (Google Fonts, Adobe Fonts) will fail. Paid plans do have external access, but self-hosting is still recommended for reliability and performance.

A managed font library with curated open-source fonts is planned.

Plans and limits

Press.js Cloud offers Free, Starter ($9/mo), and Pro ($29/mo) plans. Limits scale with each tier:

Dimension	Free	Starter	Pro
Render timeout	15s	60s	60s
Concurrent render jobs	1	10	50
External network access	—	✓	✓
Render jobs / month	500	∞	∞
Render time / month	10 min	150 min	600 min
Storage	1 GB	10 GB	50 GB

Limits are enforced both synchronously (hard limits at request time) and atomically against bill-period quotas. See Plan Limits for the full comparison and error reference.

Get started

• Quickstart — deploy your first PDF from the web dashboard in under 5 minutes
• Install the CLI — set up press for local and CI/CD workflows
• REST API — automate deploys, uploads, and rendering programmatically
• Usage & Plans — understand metering, pricing, and cost management