Public Testing Lifeboat - Deploy to Lightsail or Digital Ocean

Hello!

I have been working on an app to simplify the deploy process for Xojo Web apps. In the past couple of weeks, I have been hard at work refactoring the system to be more stable, reliable, and user friendly. I have worked out a number of issues that I had been concerned about with my initial post and feel it’s finally ready for a more public appearance.

Lifeboat build 13 is available now to anyone interested! There is more work to be done, but as a pre-release build it’s able to do most of the things the average developer will need. It’s in a great state to test and explore.

I’ve made a demo video for deploying to Digital Ocean this time around.

There’s also a little information (and the Lightsail tutorial) available on the website now:

I would urge folks to practice safe testing protocol by not using this with production environments, but I’m totally guilty of using Lifeboat to deploy WebKit. Please know that during the testing phase, Lifeboat will connect to my website to ensure it’s the latest build.

Download links:
https://strawberrysw.com/lifeboat/get/mac
https://strawberrysw.com/lifeboat/get/windows

Would love all feedback, including feature requests! (Ubuntu is on the list)

Best wishes,
Tim Parnell

8 Likes

Well done video.

When I’ve deployed web apps before, I had to transmit the app to the server, then login to the server via ssh and execute some commands. I gather your software takes care of all these steps?

What if the app does not have a front-end but just runs as a REST service? I guess that’s no differences to your solution, because all it does is taking care of uploading the files and relaunching them?

Though, as you mention nginx, I suspect that you do some more configuration that my case wouldn’t need?

Yup, you can use Lifeboat to deploy a Xojo Web app without any other tools :slight_smile:

Yup, whether you’re using sessions or just responding to HandleURL, it doesn’t matter to Lifeboat.

I use nginx for two things.

One is name management, so that you can host more than one app on a server. To do this, I use the reverse proxy features. The web app does not use port 80 or 443, instead it runs internally and nginx redirects communication. This means that every web app needs a domain or subdomain.

The second is load balancing. It’s as easy as changing the number of instances in Lifeboat. The app will then configure nginx and set up the appropriate number of systemd services. Lifeboat manages the port assignments and configuration files.

Thank you for the compliments on the video :slight_smile:

This is critical information to me (and probably to others) to determine whether and how this tool can assist me.

I’m currently using haproxy, in a config where I have a static number of web app instances running constantly, on different ports. And I have to make sure these instances are restarted should they crash (via init.d or something alike). How does your tool, in combination with gxinx, improve that?

It’s one of the biggest features to me. I would love suggestions for how to convey this on the website. It also sets up the default host in this way so that accessing the IP address returns nothing to the nosy folks.

Lifeboat juggles all the port assignments for you. Lifeboat handles that App A needs 4 instances and App B needs 1, gives each instance a port assignment, and writes the configuration files for you.

Lifeboat also configures the apps to run as systemd services. This will restart the apps if they crash or the server reboots. It is almost the same thing you’ve configured manually, but it’s all handled by software instead.

1 Like

Sounds awesome.

How would I handle Staging vs. Production setups? I guess I have to simply create separate subdomains and then handle them as if they were different apps?

In a next version, make it more configurable. Those features are great, but for many cases I probably will need just to upload and set an app set as an autorun daemon service into a very small instance (without nginx) responding at port #set by IP. The naming would be external.

What exactly do you mean by staging vs production setups?

The reason I ask is because when you go to update an app, Lifeboat uploads it to what I call a staging location. This does not affect users running the web app. When everything is uploaded, I call the next step deploy. This performs a very fast “stop app, swap app, start app”. Downtime is next to nothing.

If you’re talking more like a testing situation, I would agree with your two apps configuration.

Also, for another version, think in an option to install “webservices” instead of only Web Apps. It means, just console apps as daemon with an option of being set with a readable parameter, the usual
–port=# the dev will read and take in consideration. It’s great for JSON or XML services.

So the first part of Lifeboat (Lifeboat 2?) would be “What you want to do?” and continue from there.

We’re talking about different meanings of “staging”. I mean the setup where you have two running deployments, one for testing and one that has been validated and that the “regular” visitors see.

1 Like

I had that feeling :slight_smile:
Yes, I would run them as two different apps in Lifeboat.

These are a couple of great ideas. I’ll have to find a good way to design the system so that power users can configure things with a little more control.

2 Likes

An update, Build 15 is now available :slight_smile:

This update has a help book!

New: SSL History viewer
New: Web app log viewer
New: Warning when attempting to enable SSL on an IP address (Lets Encrypt does not support this)
New: Added Help Book
Fixed: Deploy after a failure will now reconfigure failed aspects
Changed: Preferences is now Edit > Options on Windows

Download links:
https://strawberrysw.com/lifeboat/get/mac
https://strawberrysw.com/lifeboat/get/windows

Best wishes,
Tim Parnell

2 Likes

I have no knowledge on setting up a server and I can tell you that this app worked flawlessly to deploy my Web 2.0 app to LightSail. Just followed the instructions on your video. Now I have myapp1.com working on my LightSail instances but I want to deploy myapp2.com, do I need to create another LightSail instance? At the end if I need to make an instance for each app (3.5 dls a month for each and 13.5 dls a month for a PostgreSQL database) it seems like there is no major difference in cost compared to XojoCloud.

Lifeboat is able to manage multiple web apps on one server. Press the plus button to create another web app on the same server.

You can also install Postgres right into your vps. If you need the power of Amazon RDS, that’s something you’d have to calculate with your Xojo Cloud totals as well.

I’m glad it was able to successfully start an app for you :slight_smile:

Best wishes,
Tim Parnell

I get: Validation Error webapp1 is already using this web address:

Each web app needs a different address. If you are trying to load balance then increase the instance count.

Hello again!

A new build, Build 16 is available today for testing! I’ve brought over the connections window from my other tools, giving Lifeboat a unified look :slight_smile:

Other changes:
New: Check for Updates function
New: Protects users from uploading CGI build
New: Protects users from uploading Windows build
New: Dark mode help book
Fixed: Prevents rare case of infinite not installed errors
Changed: Updated documentation for clarity
Changed: Each service is now given a log file
Changed: Redesigned connection window

Testing has been great. Thanks to everyone helping I’ve been able to resolve a number of issues. With this build, I think we’re on the final stretch of testing. Very exciting to see this app come to life, I’ve been dreaming about it all year.

Download links:
https://strawberrysw.com/lifeboat/get/mac
https://strawberrysw.com/lifeboat/get/windows

Best wishes,
Tim Parnell

2 Likes

Hello Tim, What about Debian ? I’m having several servers running Debian 9.x 10.x and I would like to do some tests there as well and see if I can use this. Unfortunately when I try to run it I get the message that os is not supported.

Thanks.

I will have to think about Debian. Supporting flavors that I don’t personally use is a larger task than it might seem and runs the risk of having failures I will never know about.

I can’t say that Debian support will absolutely be available, it may eventually happen but it’s not high enough on my list right now.