Dropserver is an application platform for your personal web services.
See Dropserver.org for details on the project.
Dropserver is written mainly in Go, but uses Deno as the the sandbox for app code. Deno is not packaged with the DS executables, instead it must be installed separately.
This repository builds two executables:
ds-hostis the complete server that can run apps in appspaces and responds to requests directed at those appspaces. It should run on a cloud VM or on a home server. Linux/x86_64 only.
ds-devis intended to run locally and is used to run Dropserver applications while they are being developed. Builds for Linux and Mac are available.
High level directories of Dropserver repo:
/cmd/ds-hostis where most of the Go code lives
ds-devGo code. It pulls in a lot of packages from the
/denosandboxcodeis Deno Typescript code that runs in each sandbox
frontend-ds-devare the frontend code (Vue 3)
/internaladditional Go code that is not specific to Dropserver
/scriptslocal build scripts for
Although it goes against Go's recommendations I favor lots of small packages.
The organization of the Go code is inspired by Ben Johnson's Standard Package Layout. I took the ideas and evolved them to fit the needs of this project.
Specifically, Dropserver is currently made up of two executables that share a lot of functionality, and I foresee more as the project develops. For this reason it's important to maximize the reusability of packages. This is accomplished as follows:
- If exporting a function works well enough, then do that
- For more demanding situations packages export structs. Any dependency is a field of type
interfacesuch that the package never imports the packages that it needs, they are injected at compile time.
- Types that are passed between different packages (as function parameters or return types) are defined in a global
domain.go. Each package only needs to import
domainto speak the same "language" as the rest of the code.
- The main command packages import and initialize each struct, setting fields to other initialized structs such that the interfaces are satisfied.
testmockspackage generates mocks for all packages that need to be used in testing.
- To prevent nil pointers at interfaces a
checkinjectutility can verify that each required dependency is indeed non-nil. It can also map out the dependency tree (wip).
The result of this scheme is that
ds-dev (which is a cut-down and tweaked version of
ds-host) exists with a minimal codebase strictly focused on the parts that are not common with
If you want to know how to build locally, please have a look at the Github actions that build the release. This will give you a pretty good idea of the steps you need to take.
I develop in Visual Studio Code therefore some config files in this repo are dependent on VSCode and a few extensions.
I tried to minimize the dependence on VSCode to work effectively on this project, but if there is something that can be done to make it easier for you to work in your preferred editor, please file an issue.
Having said that, here are some extensions that are helpful when working on this repo in VSCode:
Please see these docs on the dropserver.org website:
At this point a good chunk of the project is functional. You can upload app code, create appspaces, migrate, add users, and use the appspace with other users.
Dropserver is intended to run untrusted code while being exposed to the internet. As such, the security situation is broad and complex. While I try to be diligent about security while I work on the project there is no way for me to claim that yes "it's secure" at this stage.
- Treat with caution.
- Inspect app code before using.
- Don't put it up on the public internet unless it's completely isolated in a VM and don't put data on that VM you can't afford to have stolen.
- Some goroutine and memory leaks exist.
- Some functionality is missing or half-baked.
- APIs that the apps use are going to change a few times before becoming stable.
Code quality is variable. Some parts are OK, some are pretty shoddy. Sorry.
There is decent code coverage of the Go code (for a project that is not near 1.0).
There is little to no test coverage for frontend code, and
denosandboxcode coverage is sparse.
Contributions are welcome. I prefer that you start by opening an issue with your proposed contribution.
Apache License Version 2.0 (see LICENSE.txt).