Deploy

There are three ways to get a mineru-runpod endpoint running. Pick the one that matches what you need to control.

Option A — Deploy from the RunPod Hub (easiest)

Deploy this endpoint from the RunPod Hub →

New to RunPod? Create your account first, then come back and click Deploy.

This repo is published as a public Hub template. Open the listing above and click Deploy — or, from the RunPod dashboard, go to The Hub → Serverless repos, find mineru-runpod, and click Deploy. RunPod builds the image on your account, you pick a GPU pool, and you get an endpoint id. No fork, no clone, no local setup.

The template is the source, not a prebuilt image: there is no public image to pull, and RunPod builds one into your own account's registry the first time you deploy (~5–10 min, watchable in the dashboard). That also means your local machine's architecture is irrelevant — nothing is built on it. If you create an endpoint by hand and type an image name instead, the pull fails with an access error; see troubleshooting.

This is the recommended path if your goal is parsing PDFs, not customising the worker.

Option B — Fork and auto-build (for customization)

Fork this repo into your own GitHub account if you want to:

• Pin different versions of MinerU, vLLM, or other dependencies
• Modify handler.py (custom input validation, extra output formats, etc.)
• Run on a private GitHub repo

Then in the RunPod dashboard:

1. The Hub → Serverless repos → Import Git Repository, point at your fork. Branch main, Dockerfile path Dockerfile.
2. RunPod builds the image (~5–10 min, watchable in the dashboard) and gives you a template_id.
3. Create the endpoint. Pick one:
   • (B1) Dashboard, no local Python needed: Resources → Serverless → New Endpoint, select your template, set idle_timeout=10, workers_min=0, workers_max=3, FlashBoot on, GPU pool ADA_24 (RTX 4090). Save and grab the endpoint id.
   • (B2) As code, reproducible across deployments:

     cp .env.example .env       # fill RUNPOD_API_KEY and MINERU_TEMPLATE_ID
     pip install -e .[deploy]
     python deploy.py --template-id $env:MINERU_TEMPLATE_ID

     Every knob in deploy.py --help matches a setting in the dashboard.

Subsequent pushes to main on your fork rebuild the image automatically; the endpoint picks up the new image on next cold start (or force a redeploy from the dashboard).

Option C — Bring your own image

For full control over the Docker layer, build and push to Docker Hub or GHCR yourself, then:

python deploy.py --image yourhandle/mineru-runpod:0.1

This skips RunPod's auto-build entirely. Use it when you need custom base images, multi-stage builds, or air-gapped registries.

Endpoint defaults

Override any of these via flags to deploy.py (e.g. --gpu-ids AMPERE_24 --workers-max 5).

See Choosing a GPU for when to deviate from the default 24 GB pool.

What to do after deploy

RunPod gives you an endpoint id such as abcdef123456. It accepts the documented job input contract through the standard /run and /runsync endpoints.

1. Follow Clients to submit your first parse.
2. Enable OpenTelemetry if you need searchable logs, per-job traces, GPU metrics, or production alerts. The exporter is already in the image and remains off until you set an OTLP endpoint.
3. Review Scaling and tuning before raising worker or in-worker concurrency.

Before production traffic:

• Keep API keys and bucket credentials in the endpoint environment, scope them to the resources this worker needs, and keep them out of job payloads.
• Choose the input source and output mode for your document sizes. Large outputs usually need S3-compatible storage plus a bucket lifecycle policy.
• Align the client timeout with the endpoint execution timeout, then test a representative worst-case document.
• Add application-level retries and idempotency if jobs are business-critical; the starter client does not retry. Review the worker's cancellation limits before promising hard mid-parse cancellation.
• Enable OpenTelemetry with a production-safe cardinality and data-retention policy.