Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Choosing Your Setup Path

Who this is for: Anyone about to install the SDK who wants to pick the right route before downloading anything.

What you'll accomplish: Decide which walkthrough to follow, based on what you're trying to do and the hardware you have.

There are two questions to answer: do you need the TrustBridge platform, and how many machines are you spreading the work across?

Question 1: Standalone SDK, or SDK + TrustBridge?

  • Standalone SDK runs the Device, Gateway, and a small local Python cloud agent by themselves. It's the fastest way to see a Mutual Authentication OK result and confirm your hardware and toolchain work. Choose this for a first smoke test.
  • SDK + TrustBridge brings up the full management stack (backend, frontend, database, MQTT broker, and Cloud SDK agent, all in Docker) alongside the SDK. Choose this when you want to enroll devices, trigger authentication from a web UI, and work with the real device lifecycle.

Question 2: One machine, or split across machines?

  • One machine runs everything together, simplest for development.
  • Split machines put the Gateway on one host and the Device (with the physical Token attached) on another. This mirrors a realistic production topology. The Raspberry Pi walkthrough is the worked example of this.

Question 3: USB Token, Nordic Bluetooth board, or Nordic cellular board?

There are three hardware paths:

  • USB Token on a PC/Pi (most walkthroughs). The device SDK runs on a computer with a USB Token attached.
  • Nordic nRF54L15 over Bluetooth LE. The device SDK is flashed onto Nordic boards, and a Raspberry Pi acts as the BLE gateway (central) serving several boards at once. Choose this if your devices are Nordic boards talking over Bluetooth.
  • Nordic nRF9151-DK over LTE / cellular. A single board runs the gateway-mode SDK with its own crypto chip wired over SPI and talks MQTT over LTE straight to a hosted TrustBridge stack. No Pi, laptop, or local Docker. Choose this for the cellular demo.

Important: each variant uses different git branches. The BLE variant runs on release/v3.6.1; the cellular variant runs on release/v3.6.2; the USB-Token walkthroughs run on release/v3.6.0. Don't mix the sets of instructions.

Pick your launcher

Each row below points to a full walkthrough. Every walkthrough is self-contained.

Scenario Windows command Linux/macOS command Walkthrough
SDK only, no TrustBridge (standalone) .\run_standalone.ps1 bash run_standalone.sh Standalone SDK on Windows / Standalone SDK on Linux
SDK + TrustBridge stack on one machine .\run_all.ps1 --no-cloud bash run_all.sh --no-cloud (after start-all up) SDK + TrustBridge on Windows / on Linux & macOS
SDK + Hosted Trustbridge on one machine / split machines 

for gateway host:     .\run_gateway.ps1

for device host:   .\run_device.ps1

for gateway host:            bash run_gateway.sh

for device host:               bash run_device.sh

 SDK + Hosted TrustBridge on Windows/Linux/macOS
Split machines / Raspberry Pis (run on the Linux hosts) bash run_gateway.sh (gateway host) and bash run_device.sh (device host) Split Deployment on Raspberry Pi
Nordic nRF54L15 boards over Bluetooth LE .\flash_device.ps1 (flash the board) ./flash_device.sh (board) + ./run_ble_gateway.sh (Pi gateway) Nordic nRF54L15 Boards over Bluetooth LE
Nordic nRF9151-DK over LTE / cellular .\flash_cellular.ps1 -Monitor (flash the board) flash_cellular.ps1 under PowerShell 7, or west build + nrfutil by hand Nordic nRF9151-DK over LTE / Cellular

What every path needs first

No matter which path you choose, you'll complete these first:

  1. Meet the requirements, see System Requirements & Compatibility.
  2. Get your access package, see Access & Credentials: Your CyberRock Access Package.
  3. Install prerequisites for your OS, see Prerequisites on Windows / Linux / macOS.
  4. Get the code and run the setup script, see Get the Code & Run the Setup Script.

Then follow the walkthrough for the scenario you picked above.

On Windows, why WSL? The chip access, the broker, the compiled firmware, and the Python environment are all Linux. WSL provides that Linux environment on a Windows machine, so you don't need a separate Linux box just to run the stack.