Architecture and SDK Map

The decision that matters

First decide whether you are building a Stream Deck app plugin or a direct hardware controller. The language choice follows from that decision.

1. The layers

Stream Deck hardware
        |
        | HID protocol
        |
Official Stream Deck desktop app
        |
        | plugin WebSocket and SDK abstractions
        |
Plugin runtime
        |
        +-- Node.js SDK plugin code
        +-- Native console plugin code
        +-- Property inspector HTML UI

Python direct-control tools usually sit below the Stream Deck desktop app and talk to the device through HID. Official plugins sit above the desktop app and receive events from Stream Deck.

2. Choose the runtime

Runtime	Best for	Advantages	Trade-offs
TypeScript / JavaScript with @elgato/streamdeck	Normal plugins, Marketplace, fast iteration	Official path, CLI scaffold, hot reload, property inspectors, packaging	Node runtime, SDK lifecycle follows Elgato requirements
Python with streamdeck	Local automation stations, lab dashboards, custom front-ends	Direct device control, excellent scripting, easy OS/API glue	Not the normal Stream Deck plugin packaging model; can conflict with official app access
C#/.NET with StreamDeckToolkit	Native-style plugins, Windows integrations, existing .NET code	Strong typing, native app patterns, .NET ecosystem	Community toolkit, older template baseline, more manual SDK alignment
Raw WebSocket native plugin	C++, Go, Rust, custom runtimes	Maximum runtime freedom	Advanced path, more protocol work, more packaging complexity

3. JavaScript or TypeScript

Use TypeScript by default. The official scaffold is TypeScript-friendly, the SDK exposes typed events, and action settings benefit from real types.

Use plain JavaScript only when:

• the plugin is tiny,
• the team does not want TypeScript build steps,
• you are adapting an old plugin,
• type safety is not worth the extra project ceremony.

For new plugins, TypeScript usually wins because Stream Deck actions become event-driven quickly: key events, dial events, settings, device events, UI messages, and lifecycle hooks.

4. Python

Python is the right tool when you want the Stream Deck to become a physical dashboard for your own process:

• home automation,
• observability panels,
• internal operations consoles,
• test rigs,
• media/control rooms,
• kiosk-like local workflows,
• hardware experiments.

The key difference: Python direct control owns rendering. You draw images, set brightness, register callbacks, and decide every state transition. That is powerful, but it is not the same user experience as installing a Stream Deck app plugin.

5. .NET and native plugins

C# makes sense when the plugin naturally belongs in a .NET environment:

• Windows APIs,
• existing C# libraries,
• enterprise desktop integrations,
• local services already written in .NET,
• strongly typed native app workflows.

Elgato's current official docs recommend the Node.js SDK for most plugin authors and describe raw WebSocket plugins as advanced. Treat C# as a deliberate choice, not the fastest default.

6. Marketplace readiness

Question	Official TS plugin	Python HID app	C# native plugin
Works inside Stream Deck app	Yes	No, not by default	Yes, if implemented as plugin
Uses manifest.json	Yes	No	Yes
Property inspector support	Yes	No, unless you build your own UI	Yes, via plugin UI
Packaged as .streamDeckPlugin	Yes	No	Yes
Best for Marketplace	Yes	No	Possible, but heavier
Best for local-only automation	Good	Excellent	Good

7. Practical recommendation

Start with TypeScript unless the product requirement says otherwise.

Switch to Python when the project is not really a plugin, but a custom controller application that should use the deck as hardware.

Switch to C# or another native runtime only when the plugin must reuse native code or framework-specific integrations that would be worse through Node.js.