What is the difference between a Repl and a Deployment?

A Repl is a workspace — where you write and run code during development, with hibernation and preview URLs. A Deployment is a promoted, publicly-served copy of the app on stable infrastructure with its own scaling model and pricing. You develop in the Repl, deploy from the Repl, and end-users hit the Deployment. Confusing the two is the single most common source of Replit gotchas.

Do I need to learn Nix to use Replit?

No. For the vast majority of projects the default replit.nix that a template ships with is fine, and you never touch it. You only need to learn Nix when you have to add a system package that is not in the default set — a specific version of ffmpeg, a native library, an unusual compiler. When that day comes, adding one line to replit.nix is usually enough; you do not need to become a Nix expert.

What is Replit DB and when should I use it?

Replit DB is a simple key-value store scoped to a single Repl. It is perfect for prototypes and hobby projects — a few lines of code, no schema, no migrations. It is not suitable for production data at scale or anything that needs SQL, indexes, or transactions. When your app outgrows Replit DB, migrate to the managed Postgres integration or an external managed database. Do not try to bolt more onto Replit DB.

What are Replit credits and how are they different from the Core subscription?

Core is a flat monthly subscription that unlocks the workspace features — private Repls, higher resource limits, and a bundle of Agent credits. Credits are the usage unit Agent runs consume. When your bundled credits run out you can top up; heavy Agent users often do. Deployment costs are separate from both Core and credits, billed by deployment type and compute usage.

Is a preview URL the same as a Deployment URL?

No. A preview URL is *.replit.dev and belongs to a Repl in the workspace. It hibernates when the Repl hibernates and is meant for development, not production. A Deployment URL is *.replit.app (or your custom domain) and is served from the Deployments infrastructure with the scaling behaviour of its type. Never share a preview URL for production traffic — promote to a Deployment instead.

What is object storage on Replit and when should I use it?

Object storage is an S3-compatible bucket wired into your Repl or Deployment. It is where user-uploaded files, images, and video should live. Serving media from your app process instead of from object storage bloats egress bills and slows down cold starts. Signed URLs let the CDN serve bytes directly to clients, which is faster and cheaper than routing every download through your compute.

What is Neon and why does Replit mention it?

Neon is a serverless Postgres provider. Replit's managed Postgres integration uses Neon under the hood, so when you provision a database from the Repl you are actually getting a Neon project with Replit as the billing surface. This matters if you want to know whose status page to check during a database incident — it may be Neon's, not Replit's, that has the relevant update.

What happened to Replit Bounties?

Bounties was Replit's marketplace for paid contract work — users posted small jobs, developers bid, work was reviewed and paid. It was retired in 2024. You will still find references to it in older documentation and blog posts, but the marketplace itself is no longer accepting new bounties. Replit's current focus is on the Agent, the workspace, and Deployments rather than a services marketplace.

Replit glossary: 30 terms every Replit developer should know

Why a glossary is worth reading

Every developer platform grows its own vocabulary — a mix of general cloud-computing terms, framework-specific jargon, and product names that only make sense once you have used the tool for a while. Replit is no different. This glossary defines the thirty terms you will run into most often across the workspace, Agent, and Deployments products in 2026, grouped by area so you can skim to the section you actually need. Each entry is deliberately short: one or two sentences of plain English, enough to unblock you without turning into a textbook.

Workspace

Repl — a Replit workspace unit: filesystem, runtime, editor, and metadata all tied to a single project. Every Repl has a URL and can be forked, shared, or made private.
Nix — the package manager Replit uses to define system dependencies. Declared in replit.nix; each entry pins a specific package plus its transitive deps.
.replit — the workspace config file that sets the run command, entrypoint, ports, and environment. Edit this to change how the Repl starts.
Secrets — encrypted environment variables scoped to a Repl. Set in the Secrets tab, available as env vars at runtime, never visible to forkers.
Hibernation — the state a Repl enters after inactivity. It stops consuming resources; it wakes on first request or when you open the workspace.
Template — a reusable starting point for a new Repl. Language templates, framework templates, and community templates all seed a fresh Repl with sensible defaults.
Fork — a copy of an existing public Repl into your own account. The fork is fully editable; the original is untouched.
Multiplayer — real-time collaborative editing on a Repl, similar to Google Docs. Multiple humans plus an Agent can all be attached to the same workspace.

Agent

Agent run — a single autonomous session where the agent plans, edits, executes, and iterates on your prompt until it stops or is cancelled.
Tool call — the agent invoking one of its capabilities: file edit, shell command, package install, or browser preview. Every tool call is visible in the run log.
Credits — usage-based billing units consumed by Agent runs. Longer, tool-heavy runs consume more credits; short chat-only turns consume very few.
Checkpoint — a snapshot of the workspace state that the agent (or you) can roll back to if a run goes wrong.
Plan — the agent's proposed sequence of steps before it executes. You can review and edit the plan before applying.
Diff review — the mandatory step before any file edit is written to disk. The agent shows you the diff; you accept or reject.

Deployments

Autoscale — scale-to-zero serverless deployment billed by compute-seconds plus egress. Best for spiky low-average traffic.
Reserved VM — always-on VM billed at a flat rate per size. Best for realtime, websocket, or memory-holding workloads.
Static — pre-built HTML/JS/CSS served from Replit's CDN. Usually free within reasonable bandwidth.
Scheduled — cron-triggered Repl runs billed by compute-seconds per execution. Best for nightly jobs.
Custom domain — a user-owned hostname pointed at a Deployment via A or CNAME records. TLS certificates are issued automatically via ACME.
Deployment secrets — environment variables scoped to a Deployment specifically, separate from workspace Secrets. A common source of 'works in dev, 502 in prod' bugs.
Build ID — the identifier for a specific build of a Deployment. You can promote any past build back into serving traffic as a rollback mechanism.

Runtime and networking

Container — the isolated Linux environment your Repl or Deployment runs inside. Each container has its own filesystem, network, and process tree.
Cold start — the latency of spinning up a new container to serve an incoming request after a period of idleness. Autoscale has cold starts; Reserved VM does not.
Warm start — a request served by an already-running container. Sub-millisecond overhead compared to cold-start delays.
Egress — outbound bandwidth from the Deployment to clients, billed separately from compute. The most common surprise line item on a Deployments bill.
Listen port — the port your app opens its HTTP socket on. Must match what the Deployment expects to route to, otherwise the app boots and 502s.

Integrations

Replit DB — a simple key-value store scoped to a Repl. Great for prototypes, not for production data at scale.
Postgres (Neon) — managed Postgres provisioned from the workspace, powered by Neon under the hood. Full SQL, connection pooler, branching.
Object Storage — S3-compatible bucket wired into a Repl. Best place to serve user-uploaded media and offload egress from your app process.
Bounties — the (retired) marketplace for paid contract work between Replit users. Still referenced in older docs; not accepting new bounties.

How the terms fit together

The single mental model that ties this glossary together: Repls are for development, Deployments are for production, and the Agent is a way to move faster through both. You write code in a Repl, running against a container defined by your .replit and replit.nix files, with Secrets available as env vars. When you are ready to ship, you promote the app to a Deployment — Autoscale, Reserved VM, Static, or Scheduled depending on the traffic shape — with its own separate set of Deployment Secrets and its own custom domain. The Agent lives inside the Repl and can drive both development work and the deploy step. Everything else in the glossary is a variation on those three primitives.

Terms that changed meaning recently

A handful of Replit terms have shifted subtly between 2023 and 2026 and are worth flagging. 'Hacker plan' was renamed and reworked into today's Core plan tier structure; older tutorials still reference the old name. 'Always-on Repls' as a workspace feature was folded into Reserved VM Deployments; you no longer buy always-on directly on a Repl. 'Ghostwriter', the earlier AI feature, has been replaced by Replit Agent and Assistant. And 'Nix' as an exposed concept has become slightly less prominent as the default templates hide it better — the underlying package manager is unchanged, but you are less likely to touch replit.nix in 2026 than in 2022.