We got around this at my company by just pooling all of the LISTEN/NOTIFY streams into a single database connection in software, here's a sample implementation:
function software_listen(channel, callback):
if not channel_listened(channel):
sql("LISTEN " + channel)
listeners[channel].append(callback)
function on_message(channel, data):
for listener in listeners[channel]
listener(channel, data)
function unlisten(channel, listener):
listeners[channel].remove(listener)
if len(listeners[channel]) == 0:
sql("UNLISTEN " + channel)
It looks like all of the auth data is empty - maybe you logged into an account which doesn't have permission to install on that repository?
If you email me at [email protected] with your GitHub account name, webapp.io account (if any), and the name of the repository, I can take a look for you.
Practically
- We don't actually require you to use Docker, and we don't use it under the hood. The configuration (which looks like a Dockerfile) can run multiple containers in the same VM:
FROM vm/ubuntu:22.04
RUN (install docker)
RUN REPEATABLE docker-compose build
RUN BACKGROUND docker-compose up
EXPOSE WEBSITE localhost:8080
You can also just run entirely non-docker services:
RUN BACKGROUND redis-server
- The DSL will watch which files are used for each build step to skip everything you haven't changed, so builds are much faster
- You can use us to clone VMs and run Cypress tests in parallel, then promote one of the clones to a preview environment, and another to a production environment
- We're more declarative (in my opinion), we don't have a CLI. Everything is done by editing a Layerfile and git pushing it
TL;DR, we focused on a declarative configuration format to quickly build, fork, and hibernate VMs, where Fly is more focused on building/shipping docker containers (though the products do fill a similar niche)
Webapp.io's money making part (which facilitates this) is a DevOps company (CI/CD, preview environments, etc) which is already hammered with that sort of thing - see this post (from when we were called LayerCI) discussed by TravisCI for context: https://blog.travis-ci.com/2021-10-20-mining
We recently finished our firecracker-based webapp hosting platform.
It's like if Vercel and Docker had a baby: You write VM configurations in a language that looks like a Dockerfile, and every commit creates a preview environment which can be "promoted" to a production site.
Here's an example configuration:
```
FROM vm/ubuntu:18.04
RUN curl -fSsL https://deb.nodesource.com/setup_12.x | sudo -E bash
RUN apt-get install nodejs
COPY . .
RUN npm install
RUN npm run build
RUN BACKGROUND npm run start
EXPOSE WEBSITE localhost:3000
```
This product combines our firecracker-based hypervisor (200ms cold starts) with a global CDN written in Go (using Caddy for TLS termination)
We can offer everything for free because we charge for the DevOps side (CI/CD & preview environments) - we have no intention of getting users and then upselling people for hosting.
We're obviously very excited about this launch, and would love to hear your feedback.
- Watch which files are read (at the OS level) during each step, and snapshot the entire RAM/disk state of the MicroVM
- When you next push, just skip ahead to the latest snapshot
In practice this makes a generalized version of "cache keys" where you can snapshot the VM as it builds, and then restore the most appropriate snapshot for any given change.
Hey, yeah this looks somewhat similar to what we're building at https://webapp.io (nee LayerCI, YC S20)
We migrated to a fork of firecracker, but we're a fully hosted product that doesn't directly interact with GHA at all (similar to how CircleCI works), so there's some positioning difference between us and OP at the very least.