FreeBSD Support

Hi all,

After an extensive search through a number of ‘to do’ style self hosted options, I’ve settled on Vikunja. It’s best suited to my requirements and I’ve gotta say it’s just awesome in simplicity, features and implementation! (well done devs and contributors!)

I currently run a FreeNAS server, and utilise jails for all of my self-hosted apps. My question is, what is the best way to get Vikunja up and running on FreeBSD? Docker simply doesn’t work with FreeBSD. I could spin up a Linux VM, but I’d much much much prefer to run it in a jail if possible. Is FreeBSD support anticipated at any point in the near future? Is there a hacky workaround that I could implement in the interim?

Thanks in advance! :slight_smile:

Hi Skelly,

Unfortunately the xgo tool which I use for cross-compiling vikunja for various platforms does not seem to support freebsd. I’ve talked to the other maintainers and will try to provide builds for freebsd once support for it is ready.

I think the “hacky workaround” would be to use a Linux VM :upside_down_face:

In the meantime, if you don’t mind compiling vikunja for yourself you could try something like the following (not neccarily from the nas itself, this should also work from your workstation):

GOOS=freebsd GOARCH=amd64 make build

(assuming amd64 as the architecture of your nas, if you’re using something else, you’ll need to change that.)
You should be able to run the resulting binary in a freebsd jail.

You will also need to host the frontend either through nginx or apache but I assume running either of these is a solved problem on freebsd. If you have any issues regarding the configuration of them, please don’t hesitate to hit me up.

Unfortunately I can’t provide much assistance for freebsd as I’m not using it myself.


Thanks for the reply Konrad!

I’ve spent the morning trying to compile Vikunja for myself as you’ve suggested above, but as I don’t have a dev background so I’m a bit stuck. :sweat_smile:
After 3 hours of troubleshooting I FINALLY got past all of ‘missing package’ type errors when running make build. So I can run that successfully and it builds the binary for windows :slight_smile:

So now, I’ve now set GOOS=freebsd and GOARCH=amd64 ready to build for my server, however when I run either make build or make generate in CMD, I get this error:

go generate
exec: "C:\\Users\\Skelly\\AppData\\Local\\Temp\\go-build118681166\\b001\\exe\\templates_generate": file does not exist
pkg\static\static.go:17: running "go": exit status 1
make: *** [generate] Error 1

Any idea what is happening here? Looks to be an issue with the static template files

You will also need to host the frontend either through nginx or apache but I assume running either of these is a solved problem on freebsd.

And yeah, I run an nginx reverse proxy so the front end part should be a breeze :slight_smile:

Thanks for your help

I don’t get exactly the same error, but a segmentation fault, I guess that’s pretty much the same:

$ GOOS=freebsd GOARCH=amd64 make build
go generate
signal: segmentation fault (core dumped)
pkg/static/static.go:17: running "go": exit status 1

(Running on linux)

So it seems like this is not a fault in your setup but rather a general issue. I’ll take a look, hopefully this is already a known bug in the bindata library I’m using :slightly_smiling_face:

Edit: Issue:

However, I was able to build the binary with running make generate (without any env for freebsd set) first and then running make vikunja. The generate step is used to compile the mail templates directly into the binary for easier deployment. It does this by generating go code which essentially contains the templates as string constants, therefore it should not matter what os/arch it was generated for.

The “missing package” errors you mentioned are kind of interesting since afaik it should download all missing packages automatically when compiling… so maybe that’s a windows thing :thinking:

Let me know how you go with the bug and I’ll try again when it’s resolved :slight_smile:

Both make build and make generate give me the error from my last post - so I guess I’m stuck for now! :sweat_smile:

Does it work when you run make generate and then GOOS=freebsd GOARCH=amd64 make vikunja?

output of make generate:

go generate
exec: "C:\\Users\\Skelly\\AppData\\Local\\Temp\\go-build362703238\\b001\\exe\\templates_generate": file does not exist
pkg\static\static.go:17: running "go": exit status 1
make: *** [generate] Error 1

output of GOOS=freebsd GOARCH=amd64 make vikunja:

make: *** No rule to make target `vikunja'.  Stop.

I’m running the commands from within .../

This seems rather odd, it might be related to how generate works on windows (since it does not work at all).

So after thinking through what we’ve tried above, I’ve spun up a jail on my NAS and managed to successfully run generate/build directly on freebsd!!! :star_struck: No idea why I got windows involved in the first place :rofl:

Thanks again for your help! :grin:

Glad you got it working! Would you mind writing up the steps you did for the docs? (either here or directly through a PR)

Of course! :slight_smile:

Here are the notes I took while getting it up and working (note: this is for the ‘backend’ only - I haven’t had the time to start looking at the front end yet):

Vikunja installation (FreeNAS):

Jail Setup:

Create jail named vikunja

Set jail properties to ‘auto start’

Mount storage (/mnt to jailData/vikunja)

Start jail & SSH into it

Installing packages:

pkg update && pkg upgrade -y
pkg install nano git go gmake

Clone vikunja repo:

mkdir /mnt/GO/
cd /mnt/GO/
git clone
cd /mnt/GO/

Compile binaries:

go install
gmake generate
gmake build

Create folder to install backend server into:

mkdir /mnt/backend
cp /mnt/GO/ /mnt/backend/vikunja
cd /mnt/backend
chmod +x /mnt/backend/vikunja

Set vikunja to boot on startup:

nano /etc/rc.d/vikunja

Then paste into the file:


. /etc/rc.subr



load_rc_config $name
run_rc_command "$1"

Save and exit. Then execute:

chmod +x /etc/rc.d/vikunja
nano /etc/rc.conf

Then add line to bottom of file:


test vikunja now works by:

service vikunja start

Set static IP on router

Backend available through IP:



I hope this will be useful for someone in the future :slight_smile:

1 Like

I’ve added your guide to the docs: (with slight modifications)

1 Like

New user installing on FreeBSD here. I have some questions…but first a correction or two, assuming I am sanely doing things here. The following is apparently needed to get mage on a system that isn’t using go so much:

go install

then I did this

${GODIR}/bin/mage build

This seemed to produce a binary executable named “vikunja” in the top level directory I git cloned from.

Next, you provide the following commands

gmake generate
gmake build

but there is no Makefile in the github repo so these commands will not work.

Finally, some questions, please pardon my naivete here:

  • Is there a way to get vikunja to listen on a unix domain socket instead of :? This ensures that no one can use localhost exploits to access the api.
  • In a similar vein, my postgres listens on another unix domain socket. Is this configurable in vikunja and if so, how?

Thanks in advance.

Hi Dave. The migration from gmake to mage occurred within a week or so of my post. The instructions were updated at the docs link above to reflect this - I just didn’t go back and edit my original post :slight_smile:

I think someone else will be better placed to answer your unix domain socket questions, as I don’t have any experience with them myself.

Hi there!

As @HungrySkeleton already pointed out the docs are slightly more up to date than the original post here in the forum.

Currently it is not possible to make Vikunja listen on a unix socket. You can bind it to only though, that usually helps already.

You can use a unix socket for the postgres connection by just setting the socket as the database host in your configuration.

Thanks for the prompt replies! :slight_smile:

Are there any plans for having Vikunja listen on a unix socket? Not only is this more secure in many cases, but it’s also way faster. One source of this information.

1 Like

No plans currently. I’d accept a PR for that though.

For the performance: I think the performance improvements are negligible since you usually always want to expose Vikunja to the network. At that point you’ll add the overhead you’ve previously saved back in. And we’re talking about a few µs here anyway :slightly_smiling_face:

Do I submit a PR for feature requests on your gitea?

As to performance, I run many webapps proxied through nginx…for performance and security (i.e. proxy_pass as documented in your nginx reverse proxy docs). The benchmarks I have seen and performed in FreeBSD … comparing a connection to localhost vs a unix domain socket … are significant, and at scale a few microseconds is still a welcome improvement. Each API access through your proxy, if connecting to localhost, is effectively two network connections, which is 2 copies of things like socket buffers per access. If your server is handling 1000s of connections, these things add up.

That being said, I do recognize the performance argument as delving into the nitpicky. My stronger rationale is security, as you can control what UID accesses a unix domain socket easier than you can control what UID accesses

Yup, PRs should be submitted to the gitea.

That’s where I was going with that :wink:

The security argument definitely makes sense.