Anyone using lxc or lxd on ubuntu to install erpnext?

lxc (and most recently lxd) offers a better way to manage containerization (in other words - VMs) in ubuntu. I’m wondering if anyone in community has done that…we have been on lxc for a while now, and is stable. It makes managing virtual container, backup & restore very easy.

We’d be glad to share our experience with lxc, if anyone is interested. We are also looking to know from others about their experience with lxd.


just bumped over your topic which is quite dated … I am actually experimenting with LXD as my container tool of choice and have manage to install ERPNext for the first time just now

struggling a bit with accessing it from outside my host machine yet … anyway I was wondering whether you are still ‘in the LXC/LXD game’ and whether you might share how you practically run things?

@vrms - we are using LXD now. Let me know your questions, will be glad to help…

I used it for testing, and it worked fine for me. Didn’t have any problems after learning to use Lxc/lxd, which I think is great. I found it much better and faster than using a VM. Only thing was that I needed was a laundry list of commands to copy and paste, since there didn’t seem to be any gui for lcx/lxd. I didn’t have any problems accessing it remotely across my network, but I think there was some kind of work around to access the site from outside. But I was only using it locally for testing/training purposes.

I couldn’t get my head around docker, so for me it was sufficient.

Try lxc using Proxmox. It’s open source and installs on bare metal bit like Vmware Vsli . It has a full management web gui. It will give you KVM and LXC containers it will setup and manage. I’ve used the lxc for a Nextcloud install, working very well. No reason it won’t work with ERPNEXT

1 Like

playing around a bit some issues came up. The most pressing one

how do you make ERPNext served from your container accessible to your local network (not yet touching internet access in order to reduce complexity)

  • LXD host: xubuntu 16.04 (which lives in a VirtualBox VM on my laptop with bridged networking)
  • I can access the container ERPNext using the browser of my host VM
  • I can not access ERPNext from any other point within my local network (neither browser, nor ping)
  • Container’s IP is
  • host IP is 172.20.14.yyy

maybe it’s a bad idea to add VirtualBox to the mix in the first place? I did it because our server is still on 14.04 where newest LXD available is only 2.09 (from trusty backports) while 16.04 goes down with 2.12 (soon 2.13).

can anyone help? One thing I heard about was using iptables (which I have no experience whatsoever with) on the host.

@kirthi apart from this initial hurdle I’d be super interested to hear how you …

  1. handle bench update procedures
  2. use Container snapshots (if you do)
  3. publish/use your own image(s) (if you do)

I for now just launched an ubuntu:16.04 container, installed python-minial & ran the easy install script inside of it and go from there. I guess utilizing all tools a LXD container offers can make implementation/maintenance very easy and even scriptable

1 Like

@vrms - will try to cover the questions as much as possible.

  1. Ubuntu host in a VM - I have not tried that. It definitely sounds like complicated since you have to bridge the containers to the lxd host and the host to your VM host. Already LXD bridging is confusing sometimes. I have a Ubuntu 16.04 host dedicated machine in which the containers are bridged. This link helped me in establishing the networking of containers in LXD -
    If you need help - I can provide the settings I have.
  2. bench update procedures - I do bench updates on a weekly basis and take backup of the ocntainers before I do - This helps in quick restoration in case bench update goes wrong.
  3. Snapshots - Yes I do take snapshots - for regular backups and one just before doing bench update. snapshots are super easy - lxc snapshot container-1 and then you can create a container out of it anytime you need by using ```lxc copy container-1/snap0 container-2
  4. Images - I used them during initial setup of ERPNesxt where I had to create differnt environments for testing production and dev. I dont use them as much anymore. Images are useful when you want to replicate the setup completely. Once a production setup of ERPNext is created - I published an image out of it and used that for creating multiple test environments. It helped save a lot of time.
  5. Scritable - The lxd commands are scriptable. My backups are scripted so that I take a snapshot or a clone of a container on a daily basis. And anytime I need to restore - I can go to the clones and restore it in seconds.

Hope this helps…


first of all thanks for your feedback, that’s really interesting

Still fighting with networking. Can you kindly specify which of the alternatives given there has worked for you?

I managed to get IP addresses of my LAN to the containers with running…

  • lxc profile device set default eth0 parent enp0s3
  • lxc profile device set default eth0 nictype macvlan
    … on my host

that looks promising but afterwards I still can not access ERPNext (nor ping the containers) from outside my host and not from inside my host any longer neither. So that hasn’t helped yet really but might be a place to start.

still stuck with this

@kirthi @fblauer would you mind to post networking settings of …

a) your LXD host machine
b) the ERPNext Container

maybe i find some wisdom in there

haven’t made any progress with my networking problems @kirthi, @fblauer would you be able to post your networking settings here sometime?

Or maybe add a networking section to my LXD-howto

Below is my lxc default profile -

name: default
config: {}
description: Default LXD profile
    name: eth0
    nictype: bridged
    parent: br0
    type: nic

In the host my network interface is configured as below -

# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#auto enp21
#iface enp21 inet dhcp

auto br0
iface br0 inet dhcp
    bridge-ifaces enp21
    bridge-ports enp21
    up ifconfig enp21 up

iface enp21 inet manual
1 Like

What I have done is - created a bridge in the host and then in the container profile I bind the container network to the bridge created in host.
after doing this - just restart networking service in host or restart the host itself. You will be able to connect to the container from anywhere in your network

thanks for sharing. It seems not to work for me though (which may be due to the fact my host is a Virtual Box machine)

still I have 4 questions about your settings

  1. by default (created by lxd init) the lxd bridged interface is lxdbr0. Have you just named yours differently during the init process? if not, how did you create that bridged interface?
  2. is the package vlan installed on your host?
  3. what’s the IP address of your container (from the range maybe)? Is it the same your users access it with?
  4. what’s the IP range of your internal network?

by default (created by lxd init) the lxd bridged interface is lxdbr0. Have you just named yours differently during the init process? if not, how did you create that bridged interface? - I gave the bridge name as br0 while doing lxd init. I didnt use lxdbr0 because I couldnt bridge appropriately.

is the package vlan installed on your host? - No. But I had to install bridge-utils in the host for the bridging to work properly

what’s the IP address of your container (from the range maybe)? Is it the same your users access it with? what’s the IP range of your internal network? - The ip address range of my containers is the same as that of my host. My users will not know whether they are accessing a lxc container or actual machine.


Nice thread. Thanks.