# Run \*\*native\*\* Elm on your server and your terminal! Yes, native!

**URL:** <https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747>\
**Category:** Show and Tell\
**Created:** [June 2, 2026, 2:03pm UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747 "2026-06-02T14:03:52Z")\
**Posts on this page:** 8\
**Page:** 2

<div class="post-metadata">

**Author:** ![wolfadex](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/wolfadex/32/2461_2.png) [@wolfadex](https://discourse.elm-lang.org/u/wolfadex)\
**Post date:** [June 10, 2026, 6:11pm UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/21 "2026-06-10T18:11:52Z")

</div>

> [@rupert](#):
>
> One way it could be accomplished could be by tagging packages with capabilities. But this would mean they are course grained at the package level.

I think this would have downstream impacts on

> [@wolfadex](#):
>
> Like I could see a future where elm-ui renames [Element.layout](https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/Element#layout) to `Element.toHtml`, and adds `Element.toTui` and `Element.toView` which respectively return `Terminal.Tui.View.View msg` and `some native graphical type`. This would make elm-ui 99% _just Elm code_ and then there’d be 3 platform specific functions for converting to the appropriate platform type.

correct? I wouldn’t want my hypothetical `elm-ui`package to require all possible output types/restrictions when I can easily control that with basic types.

```elm
toHtml : Element msg -> Html.Html msg

toTui : Element msg -> Terminal.Tui.View.View msg

```

already constrain my code in meaningful ways, and similarly

```elm
someTask : SpecificCapability -> Task e a

someCmd : SpecificCapability -> Cmd msg

```

easily and clearly constrain my effects.

* * *

> [@rupert](#):
>
> your example you used the capability key “Fs.Stdin” which suggests to me that these capabilities are intended to be more fine-grained than the package level.

I think this matches with the specificity of `Browser.Navigation.Key`, no?

---

<div class="post-metadata">

**Author:** ![dta](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/dta/32/1917_2.png) [@dta](https://discourse.elm-lang.org/u/dta)\
**Post date:** [June 10, 2026, 6:12pm UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/22 "2026-06-10T18:12:18Z")

</div>

FWIW, this relates to something I think to be a hole in the Elm security model. If a package has a function that returns a `Cmd`, there is no type-level guarantee that it’s not making a network request (and exfiltrating my data) in the way that there is with a function that something other than a command (and in the way that is impossible to achieve in most other languages!). If I were designing this, I would probably forbid packages from creating `Cmd`s directly, and instead require passing them factory functions so the application layer would have maximum control over permissions (e.g. only allowing requests to a specific domain).

---

<div class="post-metadata">

**Author:** ![damir](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/damir/32/5549_2.png) [@damir](https://discourse.elm-lang.org/u/damir)\
**Post date:** [June 10, 2026, 7:35pm UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/23 "2026-06-10T19:35:51Z")

</div>

That’s what we designed now with capabilities and demonstrated with the Fs sandbox.

Domains will also have the sandbox model. The “Endgame” chapter in the book already alludes to “_… set up a policy 'Never let a program call home, always disable http calls_’”, and chapter 4 of the web server book shows an actual UI per URL for programs that call home. (That chapter is not yet in the beta repo).

That will take shape in `0,4.0`: “no million `--allow-X` switches every invocation”

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [June 11, 2026, 10:39am UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/24 "2026-06-11T10:39:42Z")

</div>

> [@wolfadex](#):
>
> I wouldn’t want my hypothetical `elm-ui`package to require all possible output types/restrictions when I can easily control that with basic types.
> 
> ```auto
> toHtml : Element msg -> Html.Html msg
> 
> toTui : Element msg -> Terminal.Tui.View.View msg
> 
> ```

You are right - with tagged packages you would have to come up with some scheme like splitting this imaginary elm-ui up into elm-ui-core, elm-ui-browser, elm-ui-tui, and so on.

Although even as things stand, suppose we have an `elm-run/tui` and `elm/html` and want to make some UI package that consumes both, we have the issue of how to distribute that package to solve. Cannot go on [https://package.elm-lang.org/](https://package.elm-lang.org/), since that will not have the `elm-run/tui` dependency.

Or as @dta suggests, dependency injection is used to reverse the dependency arrow.

---

<div class="post-metadata">

**Author:** ![allanderek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/allanderek/32/1360_2.png) [@allanderek](https://discourse.elm-lang.org/u/allanderek)\
**Post date:** [June 12, 2026, 8:03am UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/25 "2026-06-12T08:03:51Z")

</div>

> [@rupert](#):
>
> You are right - with tagged packages you would have to come up with some scheme like splitting this imaginary elm-ui up into elm-ui-core, elm-ui-browser, elm-ui-tui, and so on.

And this has the further problem that in that case, all the types that need to be inspected for `toHtml` and `toTui` would have to be visible outside `elm-ui-core`, which means they would have to be generally visible.

---

<div class="post-metadata">

**Author:** ![damir](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/damir/32/5549_2.png) [@damir](https://discourse.elm-lang.org/u/damir)\
**Post date:** [June 20, 2026, 9:13am UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/26 "2026-06-20T09:13:12Z")

</div>

A massive Thank You to all of you great Elmers at Elm Camp this year: seeing what you do with Elm is inspiring!

The conversations were just so energizing. I’m back, doubling down on code! Super excited to ship new updates this week and get new contributors involved.

`"🫶"`

---

<div class="post-metadata">

**Author:** ![petergao](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/petergao/32/1657_2.png) [@petergao](https://discourse.elm-lang.org/u/petergao)\
**Post date:** [June 29, 2026, 6:23am UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/27 "2026-06-29T06:23:23Z")

</div>

`elm-game` is particularly interesting, as I’ve been building a game using Lamdera, but was hoping for native performance and distribution that isn’t limited to a web browser. You mentioned 0.6.0 would be when it’s likely to be released. Is there a _time_ line of when that might be? Or this is all early stage and timelines are fuzzy at best (which is totally fine, if that’s the case). Just curious, cheers!

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [July 9, 2026, 6:23am UTC](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747/28 "2026-07-09T06:23:34Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

[Previous page](https://discourse.elm-lang.org/t/run-native-elm-on-your-server-and-your-terminal-yes-native/10747.md?page=1)