docs: Rename flash run to flash dev and document implicit endpoint resolution

docs.json

@@ -391,7 +391,7 @@
               "flash/cli/overview",
               "flash/cli/init",
               "flash/cli/login",
-              "flash/cli/run",
+              "flash/cli/dev",
               "flash/cli/build",
               "flash/cli/deploy",
               "flash/cli/env",

flash/apps/build-app.mdx

@@ -80,10 +80,10 @@ uv pip install -r requirements.txt
 
 ## Step 4: Start the local API server
 
-Use `flash run` to start the API server:
+Use `flash dev` to start the API server:
 
 ```bash
-uv run flash run
+uv run flash dev
 ```
 
 Open a new terminal tab or window and test your endpoints using cURL:
@@ -100,21 +100,21 @@ curl -X POST http://localhost:8888/lb_worker/process \
     -d '{"input_data": {"message": "Hello from Flash"}}'
 ```
 
-If you switch back to the terminal tab where you used `flash run`, you'll see the details of the job's progress.
+If you switch back to the terminal tab where you used `flash dev`, you'll see the details of the job's progress.
 
 ### Faster testing with auto-provisioning
 
 For development with multiple endpoints, use `--auto-provision` to deploy all resources before testing:
 
 ```bash
-uv run flash run --auto-provision
+uv run flash dev --auto-provision
 ```
 
 This eliminates cold-start delays by provisioning all serverless endpoints upfront. Endpoints are cached and reused across server restarts, making subsequent runs faster. Resources are identified by name, so the same endpoint won't be re-deployed if the configuration hasn't changed.
 
 ## Step 5: Open the API explorer
 
-Besides starting the API server, `flash run` also starts an interactive API explorer. Point your web browser at [http://localhost:8888/docs](http://localhost:8888/docs) to explore the API.
+Besides starting the API server, `flash dev` also starts an interactive API explorer. Point your web browser at [http://localhost:8888/docs](http://localhost:8888/docs) to explore the API.
 
 To run endpoint functions in the explorer:
 

flash/apps/customize-app.mdx

@@ -145,13 +145,13 @@ For details, see:
 
 ## Test your customizations
 
-After customizing your app, test locally with `flash run`:
+After customizing your app, test locally with `flash dev`:
 
 ```bash
-flash run
+flash dev
 
 # If using uv:
-uv run flash run
+uv run flash dev
 ```
 
 This starts a development server at http://localhost:8888 with:
@@ -169,7 +169,7 @@ Make sure to test:
 
 <CardGroup cols={2}>
   <Card title="Test locally" href="/flash/apps/local-testing" icon="flask" horizontal>
-    Use `flash run` for local development and testing.
+    Use `flash dev` for local development and testing.
   </Card>
   <Card title="Deploy to Runpod" href="/flash/apps/deploy-apps" icon="rocket" horizontal>
     Deploy your application to production with `flash deploy`.

flash/apps/deploy-apps.mdx

@@ -369,6 +369,108 @@ async def classify(text: str) -> dict:
     return {"classification": result}
 ```
 
+## Call deployed endpoints from scripts
+
+After deploying your Flash app, you can call your `@Endpoint` functions directly from Python scripts. Flash automatically resolves the app context from your project structure, so in most cases you can run scripts without any additional configuration.
+
+### How it works
+
+When you run a script that calls an `@Endpoint` function, Flash:
+
+1. Detects the app context from the project directory structure.
+2. Looks up the deployed endpoint by name within the resolved app and environment.
+3. Routes the request to that endpoint using Flash's sentinel service.
+4. Returns the result to your script.
+
+This lets you reuse the same `@Endpoint` function definitions to interact with deployed endpoints without modifying your code.
+
+### Example: calling within the same script
+
+The simplest approach is to call the endpoint directly in the same file where it's defined:
+
+```python
+# gpu_worker.py
+import asyncio
+from runpod_flash import Endpoint, GpuType
+
+@Endpoint(
+    name="inference",
+    gpu=GpuType.NVIDIA_GEFORCE_RTX_4090,
+    dependencies=["torch"]
+)
+async def run_inference(data: dict) -> dict:
+    import torch
+    # Inference logic
+    return {"result": "processed"}
+
+async def main():
+    result = await run_inference({"input": "data"})
+    print(result)
+
+if __name__ == "__main__":
+    asyncio.run(main())
+```
+
+Run the script:
+
+```bash
+python gpu_worker.py
+```
+
+### Example: importing from another script
+
+You can also import and call endpoints from a separate script:
+
+```python
+# call_inference.py
+import asyncio
+from gpu_worker import run_inference
+
+async def main():
+    # Flash resolves the app context automatically
+    result = await run_inference({"input": "data"})
+    print(result)
+
+if __name__ == "__main__":
+    asyncio.run(main())
+```
+
+Run the script:
+
+```bash
+python call_inference.py
+```
+
+### Override the resolved context
+
+Flash resolves the app name from your project's directory structure. Use `FLASH_APP` and `FLASH_ENV` environment variables to override this automatic resolution when needed.
+
+A common use case is when you move a script to a different directory. Since the resolved app name depends on the directory location, moving the script changes the resolved context. To continue targeting the original app, set `FLASH_APP` explicitly:
+
+```bash
+FLASH_APP=my-app python call_inference.py
+```
+
+You can also override the environment:
+
+```bash
+FLASH_APP=my-app FLASH_ENV=production python call_inference.py
+```
+
+### Error without context
+
+If Flash cannot resolve the app context and you haven't set the environment variables, it raises an error:
+
+```text
+RuntimeError: no flash context for endpoint 'inference'. either:
+  - use 'flash dev' for local development
+  - set FLASH_APP and FLASH_ENV to target a deployed environment
+```
+
+### Automatic context in deployed workers
+
+When Flash deploys your app, it automatically sets `FLASH_APP` and `FLASH_ENV` environment variables on each worker. This enables cross-endpoint communication within your deployed application without additional configuration.
+
 ## Troubleshooting
 
 ### No @Endpoint functions found

flash/apps/initialize-project.mdx

@@ -8,7 +8,7 @@ import { LoadBalancingEndpointsTooltip, QueueBasedEndpointsTooltip } from "/snip
 
 The `flash init` command creates a new Flash project with a complete project structure, including example <LoadBalancingEndpointsTooltip /> and <QueueBasedEndpointsTooltip />, and configuration files. This gives you a working starting point for building Flash applications.
 
-Use `flash init` whenever you want to start a new Flash project, fully configured for you to run `flash run` and `flash deploy`.
+Use `flash init` whenever you want to start a new Flash project, fully configured for you to run `flash dev` and `flash deploy`.
 
 ## Create a new project
 
@@ -105,13 +105,13 @@ Once your project is set up:
 
 ```bash
 # Start the development server
-flash run
+flash dev
 
 # Open the API explorer
 # http://localhost:8888/docs
 
 # If using uv:
-uv run flash run
+uv run flash dev
 ```
 
 Make changes to your worker files, and the server reloads automatically. When you're ready, deploy with:
@@ -126,6 +126,6 @@ uv run flash deploy
 ## Next steps
 
 - [Customize your app](/flash/apps/customize-app) to add endpoints and modify configurations.
-- [Test locally](/flash/apps/local-testing) with `flash run`.
+- [Test locally](/flash/apps/local-testing) with `flash dev`.
 - [Deploy to production](/flash/apps/deploy-apps) with `flash deploy`.
 - [View the flash init reference](/flash/cli/init) for all options.

flash/apps/local-testing.mdx

@@ -1,10 +1,10 @@
 ---
 title: "Test Flash apps locally"
 sidebarTitle: "Test locally"
-description: "Use flash run to test your Flash application locally before deploying."
+description: "Use flash dev to test your Flash application locally before deploying."
 ---
 
-The `flash run` command starts a local development server that lets you test your Flash application before deploying to production. The development server runs locally and updates automatically as you edit files. 
+The `flash dev` command starts a local development server that lets you test your Flash application before deploying to production. The development server runs locally and updates automatically as you edit files.
 
 When you call a `@Endpoint` function, Flash sends the latest function code to Serverless workers on Runpod, so your changes are reflected immediately.
 
@@ -13,10 +13,10 @@ When you call a `@Endpoint` function, Flash sends the latest function code to Se
 From inside your [project directory](/flash/apps/initialize-project), run:
 
 ```bash
-flash run
+flash dev
 
 # If using uv:
-uv run flash run
+uv run flash dev
 ```
 
 The server starts at `http://localhost:8888` by default. Your endpoints are available immediately for testing, and `@Endpoint` functions provision Serverless endpoints on first call.
@@ -25,14 +25,14 @@ The server starts at `http://localhost:8888` by default. Your endpoints are avai
 
 ```bash
 # Change port
-flash run --port 3000
+flash dev --port 3000
 
 # Make accessible on network
-flash run --host 0.0.0.0
+flash dev --host 0.0.0.0
 
 # If using uv:
-uv run flash run --port 3000
-uv run flash run --host 0.0.0.0
+uv run flash dev --port 3000
+uv run flash dev --host 0.0.0.0
 ```
 
 ## Test your endpoints
@@ -96,17 +96,17 @@ print(response.json())
 The first call to a `@Endpoint` function provisions a Serverless endpoint, which takes 30-60 seconds. Use `--auto-provision` to provision all endpoints at startup:
 
 ```bash
-flash run --auto-provision
+flash dev --auto-provision
 
 # If using uv:
-uv run flash run --auto-provision
+uv run flash dev --auto-provision
 ```
 
 This scans your project for `@Endpoint` functions and deploys them before the server starts accepting requests. Endpoints are cached in `.flash/resources.pkl` and reused across server restarts.
 
 ## How it works
 
-With `flash run`, Flash starts a local development server alongside remote Serverless endpoints:
+With `flash dev`, Flash starts a local development server alongside remote Serverless endpoints:
 
 ```mermaid
 %%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#9289FE','primaryTextColor':'#fff','primaryBorderColor':'#9289FE','lineColor':'#5F4CFE','secondaryColor':'#AE6DFF','tertiaryColor':'#FCB1FF','edgeLabelBackground':'#5F4CFE', 'fontSize':'14px','fontFamily':'font-inter'}}}%%
@@ -146,11 +146,11 @@ flowchart TB
 | `@Endpoint` function code | Runpod Serverless |
 | Endpoint storage | Runpod Serverless |
 
-Your code updates automatically as you edit files. Endpoints created by `flash run` are prefixed with `live-` to distinguish them from production endpoints.
+Your code updates automatically as you edit files. Endpoints created by `flash dev` are prefixed with `live-` to distinguish them from production endpoints.
 
 ## Clean up after testing
 
-Endpoints created by `flash run` persist until you delete them. To clean up:
+Endpoints created by `flash dev` persist until you delete them. To clean up:
 
 ```bash
 # List all endpoints
@@ -179,10 +179,10 @@ Flash automatically selects the next available port if your specified port is in
 Use `--auto-provision` to eliminate cold-start delays:
 
 ```bash
-flash run --auto-provision
+flash dev --auto-provision
 
 # If using uv:
-uv run flash run --auto-provision
+uv run flash dev --auto-provision
 ```
 
 **Authentication errors**
@@ -210,4 +210,4 @@ Values in your `.env` file are only available locally for CLI commands. They are
 
 - [Deploy to production](/flash/apps/deploy-apps) when your app is ready.
 - [Clean up endpoints](/flash/cli/undeploy) after testing.
-- [View the flash run reference](/flash/cli/run) for all options.
+- [View the flash dev reference](/flash/cli/dev) for all options.

flash/apps/overview.mdx

@@ -59,7 +59,7 @@ Building a Flash application follows a clear progression from initialization to
     Start a local development server to test your application:
 
     ```bash
-    flash run
+    flash dev
     ```
 
     Your app runs locally and updates automatically. When you call an `@Endpoint` function, Flash sends the latest code to Runpod workers. [Learn more about local testing](/flash/apps/local-testing).
@@ -102,7 +102,7 @@ Flash uses a two-level organizational structure: **apps** (project containers) a
     Create boilerplate code for a new Flash project with `flash init`.
   </Card>
   <Card title="Test locally" href="/flash/apps/local-testing" icon="flask" horizontal>
-    Use `flash run` for local development and testing.
+    Use `flash dev` for local development and testing.
   </Card>
   <Card title="Deploy to Runpod" href="/flash/apps/deploy-apps" icon="rocket" horizontal>
     Deploy your application to production with `flash deploy`.

flash/cli/build.mdx

@@ -164,7 +164,7 @@ ls .flash/.build/
 ## Related commands
 
 - [`flash deploy`](/flash/cli/deploy) - Build and deploy in one step (includes `--preview` option for local testing)
-- [`flash run`](/flash/cli/run) - Start development server
+- [`flash dev`](/flash/cli/dev) - Start development server
 - [`flash env`](/flash/cli/env) - Manage environments
 
 <Note>

flash/cli/deploy.mdx

@@ -214,9 +214,9 @@ flash deploy --exclude scipy,pandas
 
 See [`flash build` - Managing deployment size](/flash/cli/build#managing-deployment-size) for more details.
 
-## flash run vs flash deploy
+## flash dev vs flash deploy
 
-See [`flash run`](/flash/cli/run#flash-run-vs-flash-deploy) for a detailed comparison of local development vs production deployment.
+See [`flash dev`](/flash/cli/dev#flash-dev-vs-flash-deploy) for a detailed comparison of local development vs production deployment.
 
 ## Troubleshooting
 
@@ -252,7 +252,7 @@ export RUNPOD_API_KEY="your_key_here"
 ## Related commands
 
 - [`flash build`](/flash/cli/build) - Build without deploying
-- [`flash run`](/flash/cli/run) - Local development server
+- [`flash dev`](/flash/cli/dev) - Local development server
 - [`flash env`](/flash/cli/env) - Manage environments
 - [`flash app`](/flash/cli/app) - Manage applications
 - [`flash undeploy`](/flash/cli/undeploy) - Remove endpoints