Bootstrap user on Docker only (no API, no UI)

[thestan12]

Hello,

I'm trying to run SFTPGo using Docker Compose in a minimal setup for production, without any web interface or REST API.

Here’s what I need:

• Disable Web UI, REST, WebDAV, FTP (only SFTP on port 2022)
• Use SQLite as the backend (default)
• Create a single SFTP user with a password and home directory
• Avoid using the REST API or web interface to provision users
• No external DB, no manual command inside the container

I couldn’t find a definitive example that works out of the box with Docker only. Is there an officially supported way to do this?

Also, secondary question: is SFTPGo lighter than OpenSSH-based solutions when handling many short-lived connections? (I have several hundred legacy clients polling every few minutes.)

Thanks in advance for any help.

[nullvalue0]

I'm not really a Docker expert but just a thought... without the Web UI or REST API, how do you plan to create that single user? Not only that but afaik the Web UI is required as the first step to set your admin password.

Maybe you could deploy it locally to get your sqlite database, and once configured then deploy it to your docker container.

Also doesn't Docker work by exposing internal container ports to the outside? If you don't route/expose the Web UI/API port then to the outside world it'll essentially be like they're disabled.

[thestan12]

Thanks for your reply,

Not exactly. We have hundreds of clients connecting regularly, and the goal is to eventually deploy on Kubernetes in order to handle load and cloud costs dynamically based on demand.

It’s also an older system: each client performs a "connect/disconnect" SFTP request every 2 minutes, for no actual reason and without transferring anything. Multiplied by hundreds, this causes a significant CPU load. Disabling the web interface in each container would help reduce the resource usage per pod. Simply not exposing the port isn't enough — the web UI still runs internally and consumes resources.

We currently have no way to prevent clients from connecting that way.

Clients go through a proxy, which is why we need to rely on a single shared user account rather than managing separate users.

We were hoping that SFTPGo could be a faster alternative to OpenSSH-based solutions, better suited for high availability and autoscaling. But in our case, the web interface and database usage are unnecessary overhead.

[drakkan]

Thanks for your reply,

Not exactly. We have hundreds of clients connecting regularly, and the goal is to eventually deploy on Kubernetes in order to handle load and cloud costs dynamically based on demand.

It’s also an older system: each client performs a "connect/disconnect" SFTP request every 2 minutes, for no actual reason and without transferring anything. Multiplied by hundreds, this causes a significant CPU load. Disabling the web interface in each container would help reduce the resource usage per pod. Simply not exposing the port isn't enough — the web UI still runs internally and consumes resources.

We currently have no way to prevent clients from connecting that way.

Clients go through a proxy, which is why we need to rely on a single shared user account rather than managing separate users.

We were hoping that SFTPGo could be a faster alternative to OpenSSH-based solutions, better suited for high availability and autoscaling. But in our case, the web interface and database usage are unnecessary overhead.

The UI overhead is minimal, but it can be disabled if needed. For your specific use case, I recommend using the memory provider. Unlike OpenSSH, SFTPGo doesn’t spawn a new process for every connection, which could result in better performance.

[thestan12]

Thank you for your response. We will test this internally.

Do you provide a built-in solution to create SFTP users via the command line (e.g., in a Dockerfile), or by injecting a JSON configuration?
Unless we're mistaken, we couldn't find anything about this in your documentation or in the sftpgo.json structure.