Development

VS Code, servedas a web page

code-server on a machine of your own.No desktop and no VNC — the editor is the page.

code-server 4.137.02 cores · 4 GBServed on 8080
hub://coder

$ dxflow workflow create --identity coder hub://coder --start --link

01Pick a machinecores, memory and a rate per hour
02Create the workflowpulled from the hub, once
03Run it, then stopstopped when the work is done
The application

The editor,and nothing around it

code-server, with zsh, git and python3 already installed.

The familiar editor

Extensions, settings and the built-in terminal, in one browser tab.

zsh, git and python3

The built-in terminal opens on a shell which already has all three.

It opens on your code

WORKING_DIR names a folder under /volume, and it opens right there.

How you run it

A passwordand a folder

Two variables, and then the editor is the whole of it.

PASSWORDThe sign-in page checks this, and there is no second way in. It ships as dxflow, and everyone reading this knows that.
WORKING_DIRA path under /volume to open in. Point it at a project and the editor lands there instead of at the root.
start it your way

$ dxflow workflow start coder --override env.app.PASSWORD=something-long

$ dxflow workflow start coder --override env.app.WORKING_DIR=projects/my-app --link

The session

One port,and a sign-in page

code-server asks for the password, and nothing else does.

8080Webthe editor itself
/volumeStoragecode, settings, extensions
Open it from anywhereStart with --link and the page comes back on an HTTPS address.
Set a password firstPASSWORD defaults to dxflow, and everyone can read this page.
Good to know

No desktopunderneath it

This is code-server, not a window streamed over VNC. The editor is the page.

One HTTP port

No VNC, no window manager, no frame buffer. That is why the image is a third of the size of the desktop entries.

zsh in the terminal

The integrated terminal opens a zsh, with python3 and git already installed and waiting.

Work belongs on the volume

Everything under /volume comes back at the next start. Anything outside it goes with the machine.

The image

Pulled once,then it stays

Coder arrives as one image. This is what comes down the first time, and what the disk should have free for it.

334Mamd64compressed, the way the registry counts it
330Marm64compressed, the way the registry counts it
20GOn diskunpacked, with room to work beside it
ghcr.io/dxflow-ai/coder:latestPublished from the hub, pulled on the first start and kept for the ones after it.
Either architectureamd64 and arm64 are both published, and the machine pulls the one it runs.
What it asks for

What it wants,and what it needs

The definition asks for 2 cores and 4 GB. The image comes up on less than that, and a start given --fit trims the ask to whatever the machine actually has.

2 cores · 4 GBAsks forwhat the definition writes down
2 cores · 2 GBRuns onthe least the image comes up on
Not neededGPUit works on the cores alone
The ask is not the floorThe definition writes down what suits the work. The image itself starts on less, which is what the second figure is.
--fit caps it to the hostA start given --fit trims each step to what the machine actually has, for that start alone. The definition is never rewritten.

Machines that fit it

Coder asks for 2 cores and 4 GB. Cheapest first.

E2 Medium
$0.0419/ hour2 cores · 4 GBStart this machine
T3 Medium
$0.052/ hour2 cores · 4 GBStart this machine
B2s
$0.052/ hour2 cores · 4 GBStart this machine
Run Coder on your own machinePick a machine that meets it, and it opens about a minute after you ask.