You will fork the baseline app, deploy your fork on Render, and confirm a research run in the browser. You keep using this same fork for every later step. Everything here still runs in one web service.
The next page traces how that run works in the UI and in code.
Clone and fork
The tutorial baseline is ojusave/workshop-demo on GitHub (workshop v1: in-process searches only).
- Fork the repo on GitHub (you will push reliability changes to this fork and deploy from it later).
- Clone your fork (replace
YOUR_GITHUB_USER):
$git clone https://github.com/YOUR_GITHUB_USER/workshop-demo.gitCloning into 'workshop-demo'...$cd workshop-demo
If you already cloned ojusave/workshop-demo, add your fork as origin and push:
$git remote set-url origin https://github.com/YOUR_GITHUB_USER/workshop-demo.git$git push -u origin main
Deploy your fork on Render
Deploy from your fork. Render should build from a repository you can keep pushing to through the tutorial.
-
In the Render Dashboard, create a Blueprint from your fork (repo contains
render.yaml), or open:https://render.com/deploy?repo=https://github.com/YOUR_GITHUB_USER/workshop-demo(replace
YOUR_GITHUB_USERwith your GitHub username). -
Connect your GitHub account and select your
workshop-demofork. -
Add the environment variables from the next section when prompted (or under Environment on the service after create).
-
Wait until the deploy status is Live, then open the service URL.
Signup and claim link
If you are running this as a workshop, share this Render signup link with attendees:
https://render.com/register?utm_source=github&utm_medium=referral&utm_campaign=ojus_demos&utm_content=hero_cta
If your workshop dashboard or slides support QR links, add a QR code for that URL so attendees can join quickly.
Why the Blueprint matters
The Blueprint is your deploy contract while the app is spinning up:
- It keeps service settings in code (
render.yaml) instead of manual dashboard clicks. - It makes redeploys repeatable as you push tutorial commits.
- It reduces setup drift across attendees because everyone starts from the same baseline infra.
Set environment variables
Create these keys before you run research. Set them on the web service in the Render Dashboard (Environment → add → Save changes).
| Variable | Required now | Where to get it |
|---|---|---|
ANTHROPIC_API_KEY | Yes | Anthropic Console → API keys |
EXA_API_KEY | Yes | Exa dashboard → API keys |
RENDER_API_KEY | No (yet) | Render API keys. You will add this later when the web service starts dispatching remote task runs. |
Both keys are used in the web process for searches and memo synthesis in this baseline.
Verify the deploy
- Health check: open
https://<your-service>/healthz. You should seeok. - UI: open your service URL. You should see a query box, four search card slots, an activity log, and a memo area.
- Run research: enter a ticker (for example
TSLA) and submit. Watch the four cards move from idle → running → done or failed, then the memo stream in.
A failed search card is expected sometimes: the repo simulates transient API errors on purpose. You will analyze why on a later page.
On this page
- Fork workshop-demo, clone your fork, and deploy that fork on Render
- Set ANTHROPIC_API_KEY and EXA_API_KEY on the web service before you run research
- Verify with /healthz and a ticker in the UI, then keep using this same fork