|
| 1 | +--- |
| 2 | +title: "Session 17: Default Developer Environment for Cardano - Notes" |
| 3 | +sidebar_label: Session Notes |
| 4 | +slug: /working-group/q2-2026/sessions/17-default-developer-environment/session-notes |
| 5 | +--- |
| 6 | + |
| 7 | +# Session 17: Default Developer Environment for Cardano - Notes |
| 8 | + |
| 9 | +A working-group discussion on what the **default developer environment** on Cardano should be: what we recommend first to a developer who has never built on the chain before, and how the ecosystem can lower the cost of "day one." |
| 10 | + |
| 11 | +> **Opening Question** |
| 12 | +> *"If a new developer wanted to build on Cardano today, what environment should we recommend first by default?"* |
| 13 | +
|
| 14 | +Cardano currently offers many ways to build and test, but there is **no universally accepted "default path."** This session maps those options, weighs their trade-offs, and proposes a recommended flow for newcomers, intermediate builders, and production teams. |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## Why this matters |
| 19 | + |
| 20 | +The first 30 minutes a developer spends with Cardano shape whether they stay. Today a new builder is faced with a menu of choices (local devnet vs public testnet, self-hosted node vs hosted provider, container vs bare install) with no clear "start here" arrow. Each option is correct for *some* audience, but presenting all of them at once is the problem. |
| 21 | + |
| 22 | +A good default environment should be: |
| 23 | + |
| 24 | +- **Fast to start**: minutes, not hours |
| 25 | +- **Realistic enough**: behaves like the network the dApp will eventually ship on |
| 26 | +- **Reset-friendly**: easy to wipe and start over without losing courage |
| 27 | +- **Path-forward**: graduating to production should not require throwing away what you learned |
| 28 | + |
| 29 | +--- |
| 30 | + |
| 31 | +## Landscape at a glance |
| 32 | + |
| 33 | +```mermaid |
| 34 | +flowchart LR |
| 35 | + Dev["New developer<br/>day 1"] --> Choice{"Which environment<br/>do we recommend?"} |
| 36 | + Choice --> Local["Local devnets<br/>Yaci DevKit / cardano-node-devnet"] |
| 37 | + Choice --> Public["Public testnets<br/>Preview / PreProd"] |
| 38 | + Choice --> Hosted["Hosted providers<br/>Blockfrost / Maestro / Koios"] |
| 39 | + Choice --> SelfNode["Self-hosted node<br/>Preview / PreProd / Mainnet"] |
| 40 | + Choice --> OneClick["One-click sandbox<br/>Docker / Codespaces / Devcontainer"] |
| 41 | +
|
| 42 | + Local -->|graduate| Public |
| 43 | + Hosted -->|graduate| Public |
| 44 | + OneClick -->|graduate| Public |
| 45 | + Public -->|graduate| SelfNode |
| 46 | +``` |
| 47 | + |
| 48 | +The arrows are the *real* question: **what should the path look like, end to end?** |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +## Core discussion areas |
| 53 | + |
| 54 | +### 1) Local devnet vs public testnet |
| 55 | + |
| 56 | +The first decision a builder faces. |
| 57 | + |
| 58 | +| Aspect | Local devnet | Public testnet (Preview / PreProd) | |
| 59 | +|---|---|---| |
| 60 | +| Startup time | seconds | depends on node sync / faucet | |
| 61 | +| Realism | low (one node, sometimes no protocol-accurate params) | high (real consensus, real timing) | |
| 62 | +| Reset cost | trivial | painful (re-fund, re-deploy) | |
| 63 | +| Offline work | yes | no | |
| 64 | +| Collaboration | hard (everyone has their own chain) | easy (shared state) | |
| 65 | +| CI friendliness | excellent | possible but slow + flaky | |
| 66 | + |
| 67 | +**Questions for the room** |
| 68 | + |
| 69 | +- Should developers start locally first, or jump straight to Preview/PreProd? |
| 70 | +- What creates the **least friction** for the very first transaction? |
| 71 | +- What gives the **most realistic experience** without overwhelming a newcomer? |
| 72 | +- Is "realism" even useful before a developer can confidently build a tx? |
| 73 | + |
| 74 | +--- |
| 75 | + |
| 76 | +### 2) Compare the main options |
| 77 | + |
| 78 | +#### Local devnets (Yaci DevKit, cardano-node devnet) |
| 79 | + |
| 80 | +**What works well** |
| 81 | + |
| 82 | +- Fast iteration loop |
| 83 | +- Full control of slot / epoch / time |
| 84 | +- Offline / local development |
| 85 | +- Easier reset between tests |
| 86 | +- Great for CI and automated testing |
| 87 | + |
| 88 | +**Where it falls short** |
| 89 | + |
| 90 | +- Doesn't reflect real network conditions (mempool, propagation, fees under load) |
| 91 | +- Additional setup complexity (Docker, ports, schemas) |
| 92 | +- Possible parameter drift from public networks |
| 93 | + |
| 94 | +**Best fit for** |
| 95 | + |
| 96 | +- SDK development |
| 97 | +- Validator / contract unit + integration testing |
| 98 | +- Rapid prototyping |
| 99 | +- CI pipelines |
| 100 | + |
| 101 | +--- |
| 102 | + |
| 103 | +#### Public testnets: Preview / PreProd |
| 104 | + |
| 105 | +**What works well** |
| 106 | + |
| 107 | +- Real consensus, real block times, real fee market |
| 108 | +- Closer to production behavior |
| 109 | +- Shared ecosystem state (other devs' contracts you can interact with) |
| 110 | +- Easier collaboration and demos |
| 111 | + |
| 112 | +**Where it falls short** |
| 113 | + |
| 114 | +- Faucet dependency (rate limits, downtime) |
| 115 | +- Occasional network instability |
| 116 | +- Slower feedback loop (epochs, propagation) |
| 117 | +- Coordination complexity for teams |
| 118 | + |
| 119 | +**Questions** |
| 120 | + |
| 121 | +- Should **Preview** become the default for newcomers? |
| 122 | +- Is **PreProd** too "late-stage" for first-day builders, or is its closer-to-mainnet parity worth the extra friction? |
| 123 | + |
| 124 | +--- |
| 125 | + |
| 126 | +#### Hosted providers (Blockfrost, Maestro, Koios) |
| 127 | + |
| 128 | +**What works well** |
| 129 | + |
| 130 | +- Fast onboarding, no infra to manage |
| 131 | +- Managed reliability and indexing |
| 132 | +- Less operational burden on the developer |
| 133 | +- Strong UX for newcomers |
| 134 | + |
| 135 | +**Where it falls short** |
| 136 | + |
| 137 | +- Centralization concerns |
| 138 | +- Paid dependency past free tiers |
| 139 | +- Abstracts infrastructure knowledge that becomes important later |
| 140 | +- Rate limits can mask real-world tx behavior |
| 141 | + |
| 142 | +**Discussion** |
| 143 | + |
| 144 | +- Is managed infra **good for onboarding**, or does it create a knowledge gap that hurts developers later? |
| 145 | +- Should learning node operations come **earlier** in the journey, or be deferred until it's actually needed? |
| 146 | + |
| 147 | +--- |
| 148 | + |
| 149 | +#### Self-hosted nodes |
| 150 | + |
| 151 | +**What works well** |
| 152 | + |
| 153 | +- Maximum sovereignty |
| 154 | +- Full network understanding (sync, peers, mempool, ledger) |
| 155 | +- Production realism |
| 156 | +- Aligned with Cardano's decentralization values |
| 157 | + |
| 158 | +**Where it falls short** |
| 159 | + |
| 160 | +- Heavy setup (sync time, disk, RAM) |
| 161 | +- Ongoing maintenance burden |
| 162 | +- Hardware / resource requirements |
| 163 | + |
| 164 | +**Question** |
| 165 | + |
| 166 | +- Should **running a node** still be considered a *core* Cardano developer skill, or is it now an SRE concern that most app developers can skip? |
| 167 | + |
| 168 | +--- |
| 169 | + |
| 170 | +### 3) Dockerized / one-click environments |
| 171 | + |
| 172 | +The interesting middle ground. |
| 173 | + |
| 174 | +**Should Cardano provide an official:** |
| 175 | + |
| 176 | +- Docker Compose setup? |
| 177 | +- Dev container? |
| 178 | +- One-click sandbox? |
| 179 | +- Cloud workspace (GitHub Codespaces / Gitpod)? |
| 180 | +- Preconfigured VSCode extension pack? |
| 181 | + |
| 182 | +> *"Could Cardano reduce onboarding friction with a **one-command** developer environment?"* |
| 183 | +
|
| 184 | +**Candidate shapes** |
| 185 | + |
| 186 | +- `docker compose up` → node + indexer + faucet + provider stub, ready in minutes |
| 187 | +- Browser-based playground (no install, no wallet; write a tx, sign with a generated key, submit to a sandboxed devnet) |
| 188 | +- GitHub Codespaces template: clone, click, code |
| 189 | +- Preconfigured `.devcontainer/` shipped with starter templates |
| 190 | + |
| 191 | +**Trade-offs to discuss** |
| 192 | + |
| 193 | +- Who owns and maintains the official image? (Intersect? CF? community?) |
| 194 | +- How do we keep parameters in sync with mainnet? |
| 195 | +- Is "browser playground" too far from real workflows to be useful, or is it the *perfect* first ten minutes? |
| 196 | + |
| 197 | +--- |
| 198 | + |
| 199 | +### 4) Recommended flow debate |
| 200 | + |
| 201 | +The deliverable for this session: **propose a default path.** Below is a strawman to argue with, not a conclusion. |
| 202 | + |
| 203 | +```mermaid |
| 204 | +flowchart TB |
| 205 | + S0["Hour 0<br/>One-click playground<br/>browser or Codespaces"] --> S1 |
| 206 | + S1["Hour 1<br/>Local devnet<br/>Yaci DevKit (docker compose up)"] --> S2 |
| 207 | + S2["Day 1–7<br/>Preview testnet<br/>hosted provider for chain reads"] --> S3 |
| 208 | + S3["Week 2+<br/>Preview + self-hosted node<br/>introduce Ogmios / Kupo"] --> S4 |
| 209 | + S4["Pre-mainnet<br/>PreProd<br/>full infra mirror of prod"] --> S5["Mainnet"] |
| 210 | +``` |
| 211 | + |
| 212 | +**Open questions** |
| 213 | + |
| 214 | +- Is the playground step worth the maintenance cost, or do we send people straight to a local devnet? |
| 215 | +- Where should **hosted provider vs self-hosted node** sit on the path? |
| 216 | +- Should **Aiken + Mesh/Lucid/Blaze + Yaci DevKit + Preview** be branded as the "default stack", or is naming a stack overreach? |
| 217 | +- What is the **single command** we want to be able to tell every new developer to run? |
| 218 | + |
| 219 | +--- |
| 220 | + |
| 221 | +## Strawman recommendation |
| 222 | + |
| 223 | +For the session to converge on something concrete, the proposal is: |
| 224 | + |
| 225 | +1. **Default starting environment**: **Yaci DevKit** (local devnet via Docker). Run `docker compose up` and you have a node, faucet, and indexer. |
| 226 | +2. **Default chain access for tutorials**: **Blockfrost free tier** on **Preview**. No faucet anxiety, no node sync, real consensus. |
| 227 | +3. **Default SDK lane**: one of MeshJS / Lucid-evo / Blaze, picked per tutorial track but **not all three in one tutorial**. |
| 228 | +4. **Graduation path**: introduce **Ogmios + Kupo + self-hosted node** *after* the developer has shipped their first working tx, not before. |
| 229 | + |
| 230 | +This is a starting point for debate, not a decree. The point of the session is to **agree on a default** so the ecosystem can point newcomers at one path with confidence. |
| 231 | + |
| 232 | +--- |
| 233 | + |
| 234 | +## Decisions to bring out of the session |
| 235 | + |
| 236 | +- [ ] One canonical "default environment" recommendation (or a small matrix by audience) |
| 237 | +- [ ] A position on whether Cardano should ship an official one-command dev environment |
| 238 | +- [ ] Assignment of who maintains it (Intersect / CF / community working group) |
| 239 | +- [ ] A documentation owner for keeping the recommendation current |
| 240 | +- [ ] A follow-up session if scope expands (e.g. a deep dive on Yaci DevKit or a playground prototype) |
| 241 | + |
| 242 | +--- |
| 243 | + |
| 244 | +## Related sessions |
| 245 | + |
| 246 | +- [Session 14: SDK Repo Walkthrough](../../14-sdk-repo-walkthrough/session-notes/readme.md) |
| 247 | +- [Session 15: dApp Architecture](../../15-dapp-architecture-demo/session-notes/readme.md) |
| 248 | +- [Session 16: UI ↔ Smart Contracts](../../16-ui-smart-contract-interaction/session-notes/readme.md) |
| 249 | + |
| 250 | +See the curated links in [Resources](../session-resources/readme.md). |
| 251 | + |
| 252 | +--- |
| 253 | + |
| 254 | +*These notes belong to the Q2 2026 Developer Experience Working Group.* |
0 commit comments