There are some additional sneaky but important benefits to a single CLI:

• No client<->server version mismatch on initial installation.
• The server existing in the client machine allows devs to tinker with Coder in their own machine, without requiring any complex setup.
• Single package installation reduces overhead when downloading from the releases page (aka all Windows users).

I think it'd be wise to collect data from users before we emphasize binary size as being a large issue. I don't like that the binary is big, but I'm sure there are things we could do to reduce it apart from separating the installation.

@deansheather where are the slim binaries stored in this model? If they are still in coderd, could the second con still occur?

Regarding con 2, I'd expect we'd change the build process so the server cannot be built without the frontend/binaries. There's no need for slim binaries so we'd change our makefile to suit

I guess I'm confused, because where would the agent script curl the agent from? If the binary isn't embedded, where would it be?

No client<->server version mismatch on initial installation.
The server existing in the client machine allows devs to tinker with Coder in their own machine, without requiring any complex setup.

I'd expect these two points to be solved by the install.sh script installing both binaries as needed.

Single package installation reduces overhead when downloading from the releases page (aka all Windows users).

My proposal is that we have two release binaries, so you could still download one or the other from GitHub releases. Windows users shouldn't be impacted unless they want to run a server manually on Windows.

I guess what I'm saying is you need slim binaries to run a server. Otherwise, how would a Linux agent pull a Coder binary that can run the server with the agent? Unless it pulled from GitHub (which would break all air-gapped usage), this wouldn't work.

@kylecarbs You and I discussed this a few weeks ago. I raised it with one large customer who said their device policies prevent any agents from being executed, as they must use virtual desktops, which I'd bet is common in some locations.

Compressed releases appear to be <100 MB, which doesn’t seem burdensome to me.

I’d change my mind if we heard significant pushback from community or customers, but until then I think what we have is working fine.

I guess what I'm saying is you need slim binaries to run a server. Otherwise, how would a Linux agent pull a Coder binary that can run the server with the agent? Unless it pulled from GitHub (which would break all air-gapped usage), this wouldn't work.

The coderd binary would just include the coder CLI binaries. There is no concept of slim

Closing for now because this isn't a task that could be done without significant breakage.

Another usecase is to let users download from the /bin dir on a coder server without them having to think about it not being a server binary. Users will be confused if they try to run a server from a slim binary that they downloaded from the server.

@deansheather Can we consider this closed, or do we want to take this a step further?

$ coder server
You are using a 'slim' build of Coder, which does not support the  server  subcommand.

Please use a build of Coder from GitHub releases:
  https://github.com/coder/coder/releases

Gonna close, feel free to reopen if I misunderstood.