Synology NAS WE deployment

I am into new territory attempting to use a Synology NAS to run a WE app. The DSM is an x86_64. I complied Linux as x86 and copied the files to a web folder. The folder is accessible externally. I have checked some blogs here on DSM use and one thing escapes me.

How do you start a web app on a DSM? I do this on OS X on CLI. After I debug I use Lingon to make sure the apps run.

How do you first get the we app to run on a DSM and then is there an equivalent to Lingon for Linux?


i read you can setup a virtual maschine with
this disc station manager.
Virtual Machine Manager

I’d choose Docker…

Links to other forum topics on that:

You can (try to) start a Xojo web app on the Synology from an ssh session. The ssh server needs to be enabled and configured in the DSM Control Panel. MacOS and Windows both ship with an ssh client that can be started from the terminal / cmd console. Once you are ssh’d into the NAS, locate the web app folder, and to save any confusion specify the tcp listen port. For instance
/volume1/xojo/myapp --port=8123

To have any chance of starting your app you will need to locate the correct version of the libunwind library (libunwind-1.2 works IIRC) and copy the contents of libunwind/lib64 folder to the \ Libs Xojo build folder, including the links.
rsync -avP ~/usr/lib64/ /volume1/xojo/myapp/myapp\ libs/

Whether your app works after you have started it is a different matter. I’ve managed to get simple forms served up from a web app to the browser. As soon as I tried something non-trivial, calling a rest API with a urlconnection control for instance, I started getting segmentation faults and ‘platform not supported’ runtime exceptions. At that stage, I bit the bullet and resorted to php.

The virtual machine (hypervisor) functionality was added into DSM a couple years back but i) is only available on post 2019 (IIRC) intel models. ii) is of very limited use due to the constrained memory. Docker I played with once and decided it was easier to run a separate physical server than manage Docker on a memory constrained platform. Refurbed i3 and i5 SFFs and NUCs are easy to come by and (relatively) cheap.

@Matthew_Stevens I was preparing to write about that very topic and update after I locate the library you identify.

Here is the response I receive on our DSM when attempting to run our XOJO WE app from the CLI.

./PDS: error while loading shared libraries: cannot open shared object file: No such file or directory

I have found similar difficulties trying to use Docker and Hypervisor. While the DSM in this case an RS820+ with maximum memory installed are great devices that perform many critical network services needs such as NAS, Security, LDAP, DNS and many more plus a handful of useful applications that keeps our data our data with no CLOUD sharing on other platforms it appears that using this to house a XOJO WE app may not be the best fit.

Thank you for that link. I will work a bit more in an effort to resolve but may need to check refurbed i3 and i5 SFFs and NUCs. Presently I am using a Mac mini with maxed out memory and SSD. However Apples decision to move away from OS X Server and recent OS upgrades the Mac mini does not have desired response anymore. It was in fact Apples decision a few years ago to significantly change OS X Server that started me looking else where for critical network services replacement. I attempted both WD and Synology solutions settling on Synology.

While Synology in particular an RS820+ may not be a fit for XOJO WE apps it more than addresses the critical network services needs and then some. If you have a suggestion for a suitable refurbed i3 and i5 SFF or NUC that would provide a good user response to web app implementation please advise.

you could use the synology to install a postgres database this works fine
also the shared folders, the users for this
and keep the mac mini only to install the xojo web app ?
and find a way to connect the mac mini th the syno for authentification ?
this could be definitely possible.

I’ve just quickly tried. No issues at all to run a Xojo Web App in a Docker Container hosted on the Synology (a DS218+ in my case).
I have even automated the creation of the Docker Image as a Post Build Script.

I might find some time this weekend to create an example and “how to”.



That may prove very helpful. Since you were able to get this to work on a 64 bit proc Synology box it appears I may not be doing something correct.

Energy your way Jürg

1 Like

If you’re interested you can get a first quick glance the final result (a CRCCalculator as a Xojo Web Application):

  • Launch on your Synology NAS
  • In the Section “Image”: Click “Add → From URL”:
    Note the above Link is for downloading the Docker Image. It won’t work in a Web Browser.
    If you want to look at the Docker Hub Repository click here: Docker Hub: jotools/crccalculator
  • Once the Image has downloaded: Select it and click ‘Run’
  • Enter a Container Name of your choice, e.g.: crccalculator
  • Click on ‘Advanced Settings’
    • In the Tab ‘Ports’: Change the default setting (automatic): Local Port: 8088 | Container Port: 80
    • click ‘Apply’ to the changed advanced settings
  • Click ‘Continue’
  • Check “ Launch Container when closing this assistant”
  • Click ‘Apply’
  • In the Section “Containers” you should see the Container with the Xojo Web Application up and running
  • Access the Xojo Web App running in Docker on your NAS: http://ip-or-address-of-nas:8088/

Note: This is my first attempt of a Xojo Web App - might well be improved :wink:

The example with documentation and “How To” will follow… :slightly_smiling_face:


Ok. Docker is something new. After you register, then create a repository do you download the XOJO WE app or point the repo to the DSM, do you create a WebHook?

So it looks like the name threw me. It looks like this loads the missing library.

You don’t necessarily need to register and create a repository on a Registry such as Docker Hub. That’s just a more convenient way to deploy.
The basic steps are: Create a Docker Image containing the Xojo Web App (that’s probably the most tricky or unknown part). Transfer the Image to the NAS running Docker (either manually, or via Registry/Docker Hub). Then you can run a Docker Container Instance using that Image to serve the Web App.

A Tutorial to get you started is in the works… it should be available in a couple of days.
I hope you can keep patience, and that it will then answer the question(s) in more detail.

Have a look at the Xojo Blog Post: Running Xojo Web Applications in Docker

It explains how you can run a Xojo Web Application in a Docker Container (running on a Synology NAS).

In case someone is interested in the example project used for the Blog, or in Build Automation (creating a Docker Image), here is the example project: Xojo Web App 2 Docker (it also contains a folder “documentation” with this Blog Post).


This is a great resource @Jürg_Otter. Thank you!


@Jürg Otter

Great reference. I am getting closer. Trying to figure out why my XOJO WE app fails to stay running in Docker. It starts then stops. I have yours running so I am not certain what the problem is.
When I click on the container Logs displays nothing. In your WE app INSPECT shows application ready and in mine there is nothing.
Not certain what I need to change. I have checked and rechecked XOJO settings. Potentially the only difference is that I include files on build. They are the same I use for OS X build and that works. The files I include are Graffiti Suite for Web 2.0.
Also I am running yours on port 8088 and mine on 8089

Here is a pic of the build

and Dockerfile

and dir

Hard to say without having yours.

One thing that comes to mind:
Are you using URLConnection or Xojo.Net.HTTPSocket?

If so, then according to Xojo’s System Requirements you’ll need libsoup 2.4.

That you could add via Dockerfile:
RUN apt-get update && apt-get install -y libunwind8 libglib2.0 libsoup2.4-1

Again… without seeing your project it’s just a blind guess.

Btw: By using System.DebugLog("My Log Entry") you’ll see that output in the Docker Container Log. Maybe helps to debug in an “old fashioned way”.

I’d start by trying to Run the WebApp on a standard Linux (Ubuntu 20.04) machine - a VM is good enough.

Especially when you’re doing quite some file related things, it’s usually not as simple as just check “Build: Linux” instead of “Build: macOS”. And Debugging on a real machine is more convenient…

Once everything works in a standard Linux environment (e.g. a Ubtunu 20.04 VM), then you can go a step further and try it in a Docker environment. It will be a bit different…

For example: there are no “users” oder “user homes” in a Docker environment. So you have to consider that as well. As soon as you’re providing additional resources, you have to consider where to add them to the Image. And have the WebApp (in “docker mode”) look for it in the right place. Easiest way is “next to the app” (I know… this contradicts the paradigm of macOS/Windows).

@Jürg_Otter Ok. The WE app in current configuration is more complex than can be implemented using Docker.

However can Docker be used to load the libunwind8 library for use by the WE app?

I can find the library however I am wondering how I get the WE app to find this library when it is looking in /user/lib64 for the libunwind8 library files or is there a way to load Ubuntu and point the WE app there?

Looking at the Docker Registry it looks like there may be a way to do this but so far I am striking out

Sure. The example Dockerfile does that already. The Xojo WebApp recognized the installed libunwind8 and can use it to work and be functional.

Right. You can’t take every existing WebApp (that’s being compiled for macOS or Windows) and just expect it to work in a Linux environment (which is what we are doing in the Blog example).

Just a couple of things that come to mind:

  • When it comes to Graffiti Suite: One probably needs to add a Build Step (Copy Files: scripts folder) for TargetLinux.
  • When using URLConnection: add the required Library libsoup 2.4 in the setup (Dockerfile)
  • Remember that it’s an isolated environment. Additional resources you’re locating in some existing folders (on your current machine/environment) will not be included or accessible. One approach is to add them to the final build folder (and include everything for the Docker Image), make sure it gets located accordingly.
  • If the Docker Container quits right after starting: The WebApp has exited. Why? Hard to Debug. Use System.Debuglog to see output in the Docker Log. It might quit because of an Unhandled Exception (e.g. NilObjectExceptions because of a different OS that you’ve built for before).
  • Debugging is much easier if you’re doing that first to/on a Ubuntu 20.04 machine (or VM). Try to have the WebApp work “isolated” in a single directory, without dependencies on User Homes, AppData locations, … Once that works, Docker is just a step away.

The Blog post is a “getting started”. It should work for most Xojo Web Apps that don’t do anything fancy and don’t have dependencies of “outside resources”. If they do, it might need some tweaking - then I hope the above thoughts are of help.

Thanks for all your help in trying to get my WE app to work in Docker. Due to the complexity of my WE app this currently will not work in Docker. However I think others may find your “getting started” blog very helpful. I know I did. Thanks for putting that together

Yes, that’s a great topic.
I had the same question since several months ago, which was never really answered. Now I can try this.
Thanks to the contributors.