If AI could write these news — we’d always post them on time.
It’s the month of September already and we are a bit overdue — but reading (and writing) this made me happy personally, as we shipped a ton of new things.
End of August, we launched our Tailscale integration.
What this does for you is … it is pretty cool (of course): you can add applications on Runway to your own tailnet to access them from anywhere, just like if they were running on your own computer or a computer next to you.
It also allows an application on Runway to access other applications and services on your tailnet.
Integrating Tailscale opens up a ton of integrations with other services — e.g. if you are running a tool in your homelab and want to access it without becoming an expert for firewalls and networking. Or think about this year’s darling: AI — your application on Runway could use that powerful server in your basement.
Add to that, Tailscale has an amazing directory of integrations on their website.
One of the reasons why we wanted to integrate with Tailscale is for our Runway Add-Ons. While your Runway applications can connect to your database, there are a few hurdles for you to access the database directly.
Without Tailscale, we would need to build our own secure way to expose databases. We also did not want to make databases public (like other providers do).
The argument can be made that all changes should be in code, etc. and automated — but let’s be real: sometimes you need to “poke around” to run an ad-hoc query — so that’s possible now:
psql or the database frontend of your choice to access the databasepg_dump)This is not zombo.com but the only limit is yourself.
To connect your application, these are the steps:
runway app config set TS_AUTHKEY=tskey-auth-...-...
runway app restart
Read on in our Tailscale guide to learn more.
Containers are meant to run a single process — and we agree. However, an application may not be a single process. Up until now, you would have to create two applications — e.g. one for your app and one for a worker.
Or use a process manager to run them in the same container? — Please don’t do this.
Our multi-process feature works using a Procfile (pioneered a long time ago by the people on Heroku). Here are two examples:
web: npm run start
worker: node worker.js
web: python server.py
worker: python server.py
When an application contains a Procfile, we build the individual containers for you and you don’t have to worry about it. All the logs are aggregated in runway app logs, you can runway app exec into each of them.
While we were at it we also added init — which runs a process (in its own environment) before your application boots (e.g. for a database migration).
Long story short — multi-process is here! I’ve included two examples here, but we have a very detailed guide (for Golang) the documentation.
Speaking of Guides!
We have too many features and never talk about them — so here is something new: guides. We are releasing two guides this month:
The guides aim to go beyond the “1-2-3 step to deploy an app” on Runway examples that we have and talk about more detailed use-cases.
So the first one is Tailscale with all the examples that we could think of what you would do with our new integration.
The second guide is Golang — including everything from deploying a basic application, an application with Golang and a bit JavaScript, multi-process apps (using the Procfile again), working with Runway Add-Ons (most apps need a database!) and more.
A Runway application gives you a *.pqapp.dev host that you can use to connect, but of course you can attach your own domain names as well.
The domain names are already available on the CLI and we now display the claimed domains in your settings in the UI as well:
In addition, we expanded the documentation to explain the process of claiming domain ownership on Runway.
We rolled out the usual updates and are working on improving the update process and build times further.
Aside from the optimizations, we also plan to enable builds locally in the future — so you can test and play around with it — or use it to create well-crafted containers that follow all the best practices without becoming an expert for Dockerfiles, Bakefiles, docker buildx or whatever else the Docker gods grace us with next!
This is an ongoing task likely for the foreseeable future. But we are getting there.
Our aim with Runway is to deploy (almost) anything with as little configuration as possible. Our buildpacks pipeline enables that today. And even if you have configure one of the buildpacks, it’s not in vein: nothing (or very, very little) is Runway specific!
We made lots of small tweaks for UI/UX of the docs over the past weeks, but we also added new content. We try to be short — though Google doesn’t seem to like it. Most examples can be copy-pasted now and formatting was improved while we were at it.
Since I spent a lot of time in my life with PHP, it’s great to see that PHP is still alive and well today. Every update to the language seems for the better and I am always looking for an excuse to use it again.
So I did for the documentation — we added two new pages:
The example about extensions also includes an example to connect to your database (Runway Add-Ons).
We expanded the examples how to run Jekyll on Runway. Also includes some Rakefile magic.
Last but not least: the best feedback is customer feedback! We added a short page to detail how application configuration works on Runway and what happens when you runway app config set — where all that ends up.
Thanks for reading — please share in your networks and as always: stay tuned for more.