chore: rename workers -> actors

CLAUDE.md

@@ -14,7 +14,7 @@
 Always include a README.md for new packages. The `README.md` should always follow this structure:
 
     ```md
-    # RivetKit {subname, e.g. library: RivetKit Workers, driver and platform: RivetKit Redis Adapter, RivetKit Cloudflare Workers Adapter}
+    # RivetKit {subname, e.g. library: RivetKit Actors, driver and platform: RivetKit Redis Adapter, RivetKit Cloudflare Workers Adapter}
 
     _Lightweight Libraries for Backends_
 
@@ -30,16 +30,16 @@ Always include a README.md for new packages. The `README.md` should always follo
 
 ## Common Terminology
 
-- **Worker**: A stateful, long-lived entity that processes messages and maintains state
-- **Manager**: Component responsible for creating, routing, and managing worker instances
-- **Remote Procedure Call (RPC)**: Method for an worker to expose callable functions to clients
-- **Event**: Asynchronous message sent from an worker to connected clients
+- **Actor**: A stateful, long-lived entity that processes messages and maintains state
+- **Manager**: Component responsible for creating, routing, and managing actor instances
+- **Remote Procedure Call (RPC)**: Method for an actor to expose callable functions to clients
+- **Event**: Asynchronous message sent from an actor to connected clients
 - **Alarm**: Scheduled callback that triggers at a specific time
 
 ### Coordinated Topology Terminology
 
-- **Peer**: Individual worker instance in a coordinated network
-- **Node**: Physical or logical host running one or more worker peers
+- **Peer**: Individual actor instance in a coordinated network
+- **Node**: Physical or logical host running one or more actor peers
 
 ## Build Commands
 
@@ -56,19 +56,19 @@ Run these commands from the root of the project. They depend on Turborepo, so yo
 
 ### Topologies
 
-rivetkit supports three topologies that define how workers communicate and scale:
+rivetkit supports three topologies that define how actors communicate and scale:
 
-- **Singleton:** A single instance of an worker running in one location
-- **Partition:** Multiple instances of an worker type partitioned by ID, useful for horizontal scaling 
-- **Coordinate:** Workers connected in a peer-to-peer network, sharing state between instances
+- **Singleton:** A single instance of an actor running in one location
+- **Partition:** Multiple instances of an actor type partitioned by ID, useful for horizontal scaling 
+- **Coordinate:** Actors connected in a peer-to-peer network, sharing state between instances
 
 ### Driver Interfaces
 
 Driver interfaces define the contract between rivetkit and various backends:
 
-- **WorkerDriver:** Manages worker state, lifecycle, and persistence
-- **ManagerDriver:** Manages worker discovery, routing, and scaling
-- **CoordinateDriver:** Handles peer-to-peer communication between worker instances
+- **ActorDriver:** Manages actor state, lifecycle, and persistence
+- **ManagerDriver:** Manages actor discovery, routing, and scaling
+- **CoordinateDriver:** Handles peer-to-peer communication between actor instances
     - Only applicable in coordinate topologies
 
 ### Driver Implementations
@@ -110,7 +110,7 @@ This ensures imports resolve correctly across different build environments and p
   - UPPER_CASE for constants
   - Use `#` prefix for private class members (not `private` keyword)
 - **Error Handling:** 
-  - Extend from `WorkerError` base class (packages/core/src/worker/errors.ts)
+  - Extend from `ActorError` base class (packages/core/src/actor/errors.ts)
   - Use `UserError` for client-safe errors
   - Use `InternalError` for internal errors
 - Don't try to fix type issues by casting to unknown or any. If you need to do this, then stop and ask me to manually intervene.
@@ -119,7 +119,7 @@ This ensures imports resolve correctly across different build environments and p
     - Do not store `logger()` as a variable, always call it using `logger().info("...")`
     - Use structured logging where it makes sense, for example: `logger().info("foo", { bar: 5, baz: 10 })`
     - Supported logging methods are: trace, debug, info, warn, error, critical
-- Instead of returning errors as raw HTTP responses with c.json, use or write an error in packages/rivetkit/src/worker/errors.ts and throw that instead. The middleware will automatically serialize the response for you.
+- Instead of returning errors as raw HTTP responses with c.json, use or write an error in packages/rivetkit/src/actor/errors.ts and throw that instead. The middleware will automatically serialize the response for you.
 
 ## Project Structure
 
@@ -140,7 +140,7 @@ This ensures imports resolve correctly across different build environments and p
 
 ## Test Guidelines
 
-- Do not check if errors are an instanceOf WorkerError in tests. Many error types do not have the same prototype chain when sent over the network, but still have the same properties so you can safely cast with `as`.
+- Do not check if errors are an instanceOf ActorError in tests. Many error types do not have the same prototype chain when sent over the network, but still have the same properties so you can safely cast with `as`.
 
 ## Examples
 

docs/clients/javascript.mdx

@@ -4,12 +4,12 @@ icon: node-js
 ---
 
 import MvpWarning from "/snippets/mvp-warning.mdx";
-import StepDefineWorker from "/snippets/step-define-worker.mdx";
+import StepDefineActor from "/snippets/step-define-actor.mdx";
 import StepRunStudio from "/snippets/step-run-studio.mdx";
 import StepDeploy from "/snippets/step-deploy.mdx";
 import SetupNextSteps from "/snippets/setup-next-steps.mdx";
 
-The RivetKit JavaScript client allows you to connect to and interact with workers from browser and Node.js applications.
+The RivetKit JavaScript client allows you to connect to and interact with actors from browser and Node.js applications.
 
 <MvpWarning />
 
@@ -71,20 +71,20 @@ The RivetKit JavaScript client allows you to connect to and interact with worker
     </CodeGroup>
   </Step>
 
-  <StepDefineWorker />
+  <StepDefineActor />
 
   <Step title="Create your client">
-    Create a file `src/client.ts` in your project to connect to your worker:
+    Create a file `src/client.ts` in your project to connect to your actor:
 
     ```typescript src/client.ts
     import { createClient } from "rivetkit/client";
-    import type { App } from "../workers/app";
+    import type { App } from "../actors/app";
 
     async function main() {
       // Replace with your endpoint URL after deployment
       const client = createClient<App>("http://localhost:6420");
 
-      // Get or create a worker instance
+      // Get or create a actor instance
       const counter = await client.counter.get();
 
       // Subscribe to events
@@ -139,5 +139,5 @@ The RivetKit JavaScript client allows you to connect to and interact with worker
 
 ## Next Steps
 
-See the [Interacting with Workers](/concepts/interacting-with-workers) documentation for information on how to use the client.
+See the [Interacting with Actors](/concepts/interacting-with-actors) documentation for information on how to use the client.
 

docs/clients/python.mdx

@@ -4,12 +4,12 @@ icon: python
 ---
 
 import MvpWarning from "/snippets/mvp-warning.mdx";
-import StepDefineWorker from "/snippets/step-define-worker.mdx";
+import StepDefineActor from "/snippets/step-define-actor.mdx";
 import StepRunStudio from "/snippets/step-run-studio.mdx";
 import StepDeploy from "/snippets/step-deploy.mdx";
 import SetupNextSteps from "/snippets/setup-next-steps.mdx";
 
-The RivetKit Python client provides a way to connect to and interact with workers from Python applications.
+The RivetKit Python client provides a way to connect to and interact with actors from Python applications.
 
 <MvpWarning />
 
@@ -39,7 +39,7 @@ The RivetKit Python client provides a way to connect to and interact with worker
     ```
   </Step>
 
-  <StepDefineWorker />
+  <StepDefineActor />
 
   <Step title="Create your client">
     Create a new file `main.py`:
@@ -53,7 +53,7 @@ The RivetKit Python client provides a way to connect to and interact with worker
             # Replace with your endpoint URL after deployment
             client = AsyncClient("http://localhost:6420")
 
-            # Get or create a worker instance
+            # Get or create a actor instance
             counter = await client.get("counter")
 
             # Subscribe to events using callback
@@ -82,7 +82,7 @@ The RivetKit Python client provides a way to connect to and interact with worker
         # Replace with your endpoint URL after deployment
         client = Client("http://localhost:6420")
 
-        # Get or create a worker instance
+        # Get or create a actor instance
         counter = client.get("counter")
 
         # Subscribe to events using callback

docs/concepts/cors.mdx

@@ -8,8 +8,8 @@ Cross-Origin Resource Sharing (CORS) is a security mechanism that allows a web a
 
 You'll need to configure CORS when:
 
-- **Local Development**: You're developing locally and your client runs on a different port than your worker service
-- **Different Domain**: Your frontend application is hosted on a different domain than your worker service
+- **Local Development**: You're developing locally and your client runs on a different port than your actor service
+- **Different Domain**: Your frontend application is hosted on a different domain than your actor service
 
 ## Example
 
@@ -18,7 +18,7 @@ import { setup } from "rivetkit";
 import counter from "./counter";
 
 const registry = setup({
-  workers: { counter },
+  actors: { counter },
   // Change this to match your frontend's origin
   cors: { origin: "https://yourdomain.com" }
 });

docs/concepts/edge.mdx

@@ -1,14 +1,14 @@
 ---
 title: Edge Networking
-description: Workers run near your users on your provider's global network (if supported).
+description: Actors run near your users on your provider's global network (if supported).
 icon: globe
 ---
 
 ## Region selection
 
 ### Automatic region selection
 
-By default, workers will choose the optimal region based on the client's location.
+By default, actors will choose the optimal region based on the client's location.
 
 <Note>
 	Under the hood, Rivet uses [Anycast routing](https://en.wikipedia.org/wiki/Anycast) to automatically find
@@ -17,16 +17,16 @@ By default, workers will choose the optimal region based on the client's locatio
 
 ### Manual region selection
 
-The region a worker is created in can be overridden using region options:
+The region a actor is created in can be overridden using region options:
 
 ```typescript client.ts
 import { createClient } from "rivetkit/client";
 import type { App } from "./src/index";
 
 const client = createClient<App>("http://localhost:6420");
 
-// Create worker in a specific region
-const worker = await client.example.get({
+// Create actor in a specific region
+const actor = await client.example.get({
   options: {
     create: {
       region: "atl"
@@ -35,7 +35,7 @@ const worker = await client.example.get({
 });
 ```
 
-See [Create & Manage Workers](/docs/manage) for more information.
+See [Create & Manage Actors](/docs/manage) for more information.
 
 ## Available regions
 
@@ -45,6 +45,6 @@ See available regions [here](/docs/regions).
 
 It's common to need to display a list of available regions in your application.
 
-To fetch a full list of regions, you can use the `GET https://api.rivet.gg/regions` HTTP endpoint. See API documentation [here](/docs/api/worker/regions/list).
+To fetch a full list of regions, you can use the `GET https://api.rivet.gg/regions` HTTP endpoint. See API documentation [here](/docs/api/actor/regions/list).
 
 We don't recommend hard-coding the region list. This allows you to develop your application with a local development cluster.

docs/concepts/external-sql.mdx

@@ -3,9 +3,9 @@ title: External SQL Database
 icon: database
 ---
 
-While workers can serve as a complete database solution, they can also complement your existing databases. For example, you might use workers to handle frequently-changing data that needs real-time access, while keeping less frequently accessed data in your traditional database.
+While actors can serve as a complete database solution, they can also complement your existing databases. For example, you might use actors to handle frequently-changing data that needs real-time access, while keeping less frequently accessed data in your traditional database.
 
-Workers can be used with common SQL databases, such as PostgreSQL and MySQL.
+Actors can be used with common SQL databases, such as PostgreSQL and MySQL.
 
 ## Libraries
 
@@ -35,8 +35,8 @@ There are several options for places to host your SQL database:
 
 Here's a basic example of how you might set up a connection to a PostgreSQL database using the `pg` library:
 
-```typescript worker.ts
-import { worker } from "rivetkit";
+```typescript actor.ts
+import { actor } from "rivetkit";
 import { Pool } from "pg";
 
 // Create a database connection pool
@@ -48,16 +48,16 @@ const pool = new Pool({
   port: 5432,
 });
 
-// Create the worker
-const databaseWorker = worker({
+// Create the actor
+const databaseActor = actor({
   state: {
     // Local state if needed
     lastQueryTime: 0
   },
 
   // Initialize any resources
   onStart: (c) => {
-    console.log("Database worker started");
+    console.log("Database actor started");
   },
 
   // Clean up resources if needed
@@ -98,15 +98,15 @@ const databaseWorker = worker({
   }
 });
 
-export default databaseWorker;
+export default databaseActor;
 ```
 
 ## With Drizzle ORM
 
 Here's an example using Drizzle ORM for more type-safe database operations:
 
-```typescript worker.ts
-import { worker } from "rivetkit";
+```typescript actor.ts
+import { actor } from "rivetkit";
 import { drizzle } from "drizzle-orm/node-postgres";
 import { pgTable, serial, text, timestamp } from "drizzle-orm/pg-core";
 import { Pool } from "pg";
@@ -127,10 +127,10 @@ const pool = new Pool({
 // Initialize Drizzle with the pool
 const db = drizzle(pool);
 
-// Create the worker
-const userWorker = worker({
+// Create the actor
+const userActor = actor({
   state: {
-    // Worker state (frequently accessed data can be cached here)
+    // Actor state (frequently accessed data can be cached here)
     userCache: {}
   },
 
@@ -169,5 +169,5 @@ const userWorker = worker({
   }
 });
 
-export default userWorker;
+export default userActor;
 ```

docs/concepts/logging.mdx

@@ -3,11 +3,11 @@ title: Logging
 icon: list-ul
 ---
 
-Workers provide a built-in way to log complex data to the console.
+Actors provide a built-in way to log complex data to the console.
 
 When dealing with lots of data, `console.log` often doesn't cut it. Using the context's log object (`c.log`) allows you to log complex data using structured logging.
 
-<Note>Using the worker logging API is completely optional.</Note>
+<Note>Using the actor logging API is completely optional.</Note>
 
 ## Log levels
 
@@ -46,9 +46,9 @@ Consider this example:
 <CodeGroup>
 
 ```typescript structured_logging.ts
-import { worker } from "rivetkit";
+import { actor } from "rivetkit";
 
-const counter = worker({
+const counter = actor({
   state: { count: 0 },
 
   actions: {
@@ -64,9 +64,9 @@ const counter = worker({
 ```
 
 ```typescript unstructured_logging.ts
-import { worker } from "rivetkit";
+import { actor } from "rivetkit";
 
-const counter = worker({
+const counter = actor({
   state: { count: 0 },
 
   actions: {
@@ -92,13 +92,13 @@ Additionally, structured logs can be parsed and queried at scale using tools lik
 The logger is available in all lifecycle hooks:
 
 ```typescript
-import { worker } from "rivetkit";
+import { actor } from "rivetkit";
 
-const loggingExample = worker({
+const loggingExample = actor({
   state: { events: [] },
 
   onStart: (c) => {
-    c.log.info('worker_started', { timestamp: Date.now() });
+    c.log.info('actor_started', { timestamp: Date.now() });
   },
 
   onBeforeConnect: (c, { params }) => {
@@ -137,7 +137,7 @@ const loggingExample = worker({
   },
 
   actions: {
-    // Worker actions...
+    // Actor actions...
   }
 });
 ```