Public vs Private Template Settings

Every Pod you launch starts with a handful of decisions. You pick a container image, ports, disk size, and environment variables. A template saves those decisions so you make them once and reuse them.

Once you’ve built a template of your own, you face one more choice: who else gets to use it. That’s what this guide covers. We’ll go through what a template contains, where templates come from, what changes between public and private, and how to create, update, and manage your own.

If you haven’t built a template yet, start with [Building Runpod templates: Your first custom template]. Come back here when you’re ready to decide how to share it.

What a template is

A template is a saved deployment configuration. It includes:

• Container image, plus registry credentials if the image is private
• Start command (optional), which overrides the image’s default
• Ports: HTTP ports exposed through Runpod’s proxy, and TCP ports for things like SSH
• Storage: container disk size, volume disk size, and mount path
• Environment variables, including references to Runpod secrets
• Compute type: NVIDIA GPU, AMD GPU, or CPU

In short, a template is a collection of information that lets you get a Pod or Serverless configuration up and running with a set of pre-defined parameters. Sure, you could manually specify fields like start commands every time you launch a Pod, but who has time for that? Templates save you minutes of configuration every time you need to start something up, which translates to hours or days of saved time over the long haul.

Where templates come from

It helps to treat this as two separate questions: who made the template, and who can see it.

Who made it:

• Official templates are built and maintained by Runpod. For example, the PyTorch templates were recently consolidated onto PyTorch 2.13 with a choice of CUDA versions.
• Verified templates are community templates that Runpod has verified.
• Community templates are published by other Runpod users. Runpod doesn’t maintain or support them. For help, contact the creator (they'll usually have an accompanying Github or website that explains what their template does) or ask in the Runpod Discord.
• Yours are templates you create in your account, Team, or Organization.

A template is either public or private. Official, verified, and community templates are public by definition. New templates you create are private unless you choose otherwise. Public templates can be found and deployed by anyone on Runpod. Bear in mind, however, that public doesn't mean featured. The Hub’s landing page leads with official and verified templates. Community templates, including yours once you publish, appear when someone searches. That means your template’s name and description do most of the work of getting it found. Name it for what it does, like “vLLM 0.x + OpenAI-compatible server.” A name like “my-template-v3” won’t get found. If you are interested in publicizing a template, the most successful creators will have discoverability outside of Runpod as well - Civitai, Medium, Substack, YouTube, and self-hosted websites have all served template publizhers well.

For private templates, you share them through your account structure, not through links. If a collaborator needs your private template, add them to your Team or Organization. If your account belongs to an Organization, public publishing isn’t available. This is enforced in both the console and the API, so internal configurations can’t leak by accident. Org-wide is the widest sharing option; their members can still deploy any public template from the Hub, as long as their role allows them to create Pods or endpoints.

Ownership and maintenance

You own the templates you create. In an Organization, the organization owns them, so they keep working if the person who made them leaves.

Publishing a public template means shipping a small product; this naturally engenders some level of responsibility and commitment as onther people will build workflows on it. A few habits help:

• Pin image tags. Use myimage:1.2.0, not :latest, so the people relying on your template know exactly what they’re getting.
• Know what an edit changes. Edits apply to new deployments. Pods that are already running don’t change.
• Deprecate before you delete. Deleting a template others depend on breaks their workflows without warning.
• Track your base image. Runpod updates and retires official templates over time. If your image builds FROM an official Runpod base, revisit it when new versions ship.

Maintaining a popular public template can also pay off. Through the Runpod creator program, you earn a percentage of what other users spend running Pods from your template, once it reaches one day of total runtime.

Security and privacy considerations

Treat every field of a public template as public. That includes the image name, start command, ports, and default values of environment variables. Ask yourself whether you’d paste each field into a public GitHub repo.

Never put credentials in plain environment variables. Store them as Runpod secrets and reference them with {{ RUNPOD_SECRET_name }}. The template stores only the reference, never the value.

A private template doesn’t make your image private. If your image is in a public Docker Hub repository, anyone can pull it, whatever the template’s visibility. If the image contains proprietary code or model weights, put it in a private registry and keep the template private. Public templates should point to public images.

Private means access control, not secrecy within your group. Anyone in your Team, or anyone your Organization template is shared with, can see its configuration. In Organizations, secrets are personal by default. Members with the right permission can share a secret with the whole organization.

Vet public templates before you run them. Deploying someone else’s template means running their container on your Pod. Check where the image comes from and what the start command does. For production work, prefer official and verified templates.

Create, use, update, and manage templates

Before you create a template, you'll want to have a working image since everything else hinges on that; a template with a bad image still means a failed deploy. To accomplish this, go to Templates in the console, click New Template, fill in the configuration, and click Save Template. Deploy a test Pod before sharing it with anyone.

You can also create templates programmatically:

# CLI
runpodctl template create --name "my-template" --image "myuser/myimage:1.0.0"

# REST API v2 ("public": false keeps it private)
curl --request POST https://api.runpod.io/v2/templates \
  --header "Authorization: Bearer $RUNPOD_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"name": "my-template", "image": "myuser/myimage:1.0.0",
           "category": "NVIDIA", "public": false, "serverless": false,
           "ports": ["8888/http", "22/tcp"]}'

For Serverless templates, add --serverless to the CLI command or set "serverless": true in the API request.

Wrapping up

Every template answers two questions: who made it, and who can see it. For templates you make, the second question comes down to public or private.

Private is the right home for most templates. It covers experiments, internal stacks, and anything built on proprietary code or weights. Your Team or Organization handles access, and nothing leaves your account unless you choose to share it.

Public is for templates you’re ready to support. Anyone on Runpod can deploy them, people find them through Hub search, and every field in the configuration is visible. In return, you reach a wider audience and may earn creator credits. If you’re in an Organization, org-wide sharing is as far as a template goes.

When in doubt, start private. Once your template is stable, documented, and free of anything you wouldn’t publish, making it public is a single edit away.

‍

‍

‍

‍