Live on the Edge - Beta Testers Requested

Smigit

Hourly feature drops on a weekend is quite the rapid rollout cadence

SilverCreek

Upcoming Feature: Do you use Tailscale? We've got you covered. You will be able to, in your Application Specification file, tell us to connect to your Tailnet instead of our WireGuard VPN option. We will automatically announce your private LAN to your Tailnet -- no more extra VPN profile required if you're already a Tailscale user!

This is all the configuration you'll need once we push the feature:

vpn:
  use: tailscale
  auth_key: {{ AUTH_KEY }}
  expose_lan: true

It's that simple, really.

fluffernutter

@Smigit said:
Hourly feature drops on a weekend is quite the rapid rollout cadence

vibecoding works wonders sometimes

SilverCreek

Feature Released: Tailscale VPN is now available in the public beta. Just add the below YAML to your specification file and Tailscale will automatically deploy for you, announce the internal subnet over your Tailnet. Please remember to disable key expiry or set a long expiry for prolonged use, we recommend 90 days or expiry disabled for that reason. By default, our Tailscale implementation accepts your preexisting routes as well.

For users in the beta who wish to try this out, please see the below YAML fragment for your Application Specification:

YAML Fragment:

vpn:
  use: tailscale
  auth_key: tskey-auth-....
  expose_lan: true
  accept_dns: true

Flags:

1. expose_lan exposes the internal (eg, 172.28.3.0/24) subnet to your Tailnet.
2. accept_dns accepts existing Tailscale DNS entries from your Tailnet into the container.

SilverCreek

New Template: Looking to deploy your Node.js Applications? We've got you covered now. In your Resource's role: field, specify "nodejs-22" and we'll automatically deploy your Node.js Application.

For beta test users wanting to try this, look below for instructions.

You will need to have an entrypoint.sh file to run your application's service. An example entrypoint.sh is below:

#!/bin/bash
set -e
npm install
npm run server

Kevinf100

Dam. Your hella updating this!
Suggest, maybe ad a way to allow users to make custom VPN profiles/temple.
That way the can use vpn: on multiple containers/deployments if they have other solutions setup like zerotier, netbird, netmaker, etc.

SilverCreek

New Template: Looking to deploy your Go (golang) Application? We've got you covered now. In your Resource's role: field, specify "golang-1.24" and we'll automatically deploy your Node.js Application.

For beta test users wanting to try this, look below for instructions.

You will need to have an entrypoint.sh file to run your application's service. An example entrypoint.sh is below:

#!/bin/bash
set -e
if [ ! -f "/app/dist/MyProgram" ]; then
  echo "MyProgram not found."
  exit 1
fi
chmod +x /app/dist/MyProgram
./app/dist/MyProgram

SilverCreek

@Kevinf100 said:
Dam. Your hella updating this!
Suggest, maybe ad a way to allow users to make custom VPN profiles/temple.
That way the can use vpn: on multiple containers/deployments if they have other solutions setup like zerotier, netbird, netmaker, etc.

You can use vpn: directive on multiple deployments, it will export your subnets appropriately. Each deployment has it's own unique and isolated subnet, if you plan to do lots of deployments in their own projects, just make your tailscale auth key re-usable so you don't have to use multiple keys.

We have plans to add zerotier natively to the vpn: directive, but always open to feedback if you have ones you'd like added.

SilverCreek

New Template: You can now deploy your ASP.NET Core applications on our platform, supporting both versions 8 (LTS) and 9 (Standard). In your Resource's role: field, specify either aspnet-core-8 or aspnet-core-9 and we'll automatically deploy your ASP.Net Core Application.

For beta test users wanting to try this, look below for instructions.

You will need to have an entrypoint.sh file to run your application's service. An example entrypoint.sh is below:

#!/bin/bash
set -e
if [ ! -f "./published/aspnetapp.dll" ]; then
  echo "Application was not found."
  exit 1
fi
dotnet ./published/aspnetapp.dll

SilverCreek

New Template: You can now deploy your Ruby applications on our platform, with Ruby version 3.42. In your Resource's role: field, specify ruby-3.42 and we'll automatically deploy your Ruby application.

For beta test users wanting to try this, look below for instructions.

You will need to have an entrypoint.sh file to run your application's service. An example entrypoint.sh is below:

#!/bin/bash
set -e
if [ ! -f "./my-script.rb" ]; then
  echo "My script was not found."
  exit 1
fi
chmod +x ./my-script.rb
./my-script.rb

As a reminder, you can install and compile your application using our deploy: -> run: directive, with an array of commands to execute (eg, bundle install), a generic example is below:

resources:
  web01:
    name: web01
    role: alma9-httpd-php8
    mode: container
    is_web_interface: true
    persistent_storage: false
    deploy:
      git: "[email protected]:username/gitrepo.git"
      run: ["php artisan migrate", "php artisan debug:self-test"]

cainyxues

@SilverCreek

SilverCreek

@cainyxues said:

@SilverCreek

sanvit

Hey there,

Have some questions regarding this:

1. What happens if I do 100Mbps for 1 minute and then no network activity? Will I be charged for the full 100Mbps?
2. Can I do per-GB network pricing instead of Mbps?
3. APAC where/when?
4. What’s the difference between this and Bunny.net Magic Containers/Fly.io (seems to be your main competitor?)

Thanks!

SilverCreek

@sanvit said:
Hey there,

Have some questions regarding this:

1. What happens if I do 100Mbps for 1 minute and then no network activity? Will I be charged for the full 100Mbps?
2. Can I do per-GB network pricing instead of Mbps?
3. APAC where/when?
4. What’s the difference between this and Bunny.net Magic Containers/Fly.io (seems to be your main competitor?)

Thanks!

Great questions!

1. That's not a problem.
2. We don't do per-GB network pricing, for us it makes better sense to by the Mbps 95th%.
3. We have Auckland, NZ launching and will be offering the same prices across all POPs (even Dubai when it launches).
4. Great question, and frankly both platforms are good platforms, we're aiming to do something a bit different.

Fly lets you deploy what you want quickly. Bunny does the same. Bunny has a beautiful interface for it (props to their team). They both let you deploy on the edge but you have to build your own stack -- for example, as far as I can tell, they aren't pre-provisioning VPN containers, Tailscale + Zerotier network accesses (and subnet routers), per-tenant DNS servers, etc. which we are.

Our end goal is to build this platform for someone who wants refined control of their infrastructure like Fly & Bunny give you, but with the conveniences such as the Tailscale + Zerotier, baked in DNS and other features we have in the works.

On our platform, you no longer have to define multiple containers just to expose your internal subnet over Tailscale, setup an autodiscover DNS server within your internal network, you can scale up and down with a single API call or let our max_scale: {{ INT }} directive take it.

I won't touch much on pricing, but comparing our internal pricing guideline to Fly.io for example, we're significantly cheaper. We also do not charge for how many containers or VMs you deploy, we charge just for CPUs used, memory used and storage used -- we don't charge you for what you've allocated, only what you've actually consumed -- when you reach your allocation we send an automated alert to you via our portal letting you know you've reached your allocation, we provide a temporary boost (one-time) at no cost, and if the overage isn't rectified (e.g, resource group plan upgrade, or reducing load) within 30 days we suspend the service -- we give ample opportunity to resolve any issues without any automated process kicking you, ensuring no downtime even if you go over your limits.

We also don't bill for overages at this time and I'd like to keep it that way. All our nodes have plenty of resources, and if we're all playing nice we can all benefit. If we do have to bill for overages, we'd follow our 30 day model (30 days past the overage beginning, if not rectified, would be billed at the pre-defined rate for your resource group plan).

sanvit

Thanks for the response! Indeed the product itself looks promising, and would definitely have a look. I do have a few more questions though,

@SilverCreek said: 1. That's not a problem.

Could you elaborate on this please? E.g. it doesn't matter because you bill by 95th%, or unintended spikes will not be billed, etc.

2. There seems to be no charge mentioned for RAM usage? Will this be added in the future, or is the charge only based on the CPU usage?
3. What happens if we use a fraction of the minimum billing resource (e.g. for me a single imgproxy instance uses <0.1x vCPU/mo on avg)
4. Would love to see auto suspension/wakeup based on proxy request (this) unless you are really not charging anything for RAM

SilverCreek

@sanvit said:
Thanks for the response! Indeed the product itself looks promising, and would definitely have a look. I do have a few more questions though,

@SilverCreek said: 1. That's not a problem.

Could you elaborate on this please? E.g. it doesn't matter because you bill by 95th%, or unintended spikes will not be billed, etc.

2. There seems to be no charge mentioned for RAM usage? Will this be added in the future, or is the charge only based on the CPU usage?
3. What happens if we use a fraction of the minimum billing resource (e.g. for me a single imgproxy instance uses <0.1x vCPU/mo on avg)
4. Would love to see auto suspension/wakeup based on proxy request (this) unless you are really not charging anything for RAM

1. It's not a problem because we don't charge for overages and we bill based on the 95th%. We collect metrics every 5 minutes and ship them off to our portal, so the data you'll see in our portal is delayed by 5 minutes but is an accurate representation of the usage (CPU %, Memory Used, Storage Used, Mbps Used).
2. We haven't priced out RAM usage, our goal is to make sure your applications are always available (without any suspend/wake), so I don't expect us to charge for RAM usage until someone ruins the party for everyone. If we do charge, we'd line it up at around $1/GB/mo.
3. We have a minimum charge policy, which means if your usage is less than allocated, our minimum charge is $2.232/mo -- this is the minimum you'd be paying.

SilverCreek

April 1st, 2025: Changelog for beta users.

We have released support for Application (Manifest) Specification version 1.1. Please see below for an example:

version: 1.1
customer_uuid: $CUSTOMER_UUID
project_uuid: $PROJECT_UUID
resources:
  web01:
    name: web01
    role: alma9-httpd-php8
    mode: container
    is_web_interface: true
    persistent_storage: false
    scale: 1
    deploy:
      git: "[email protected]:username/repository.git"
      run: []
  web02:
    name: web02
    role: alma9-httpd-php8
    mode: container
    is_web_interface: true
    persistent_storage: false
    scale: 1
    deploy:
      git: "[email protected]:username/repository.git"
      run: []
  mysql01:
    name: mysql01
    role: alma9-mysql
    mode: container
    is_web_interface: false
    persistent_storage: true
    environment:
      sql_password: abcdefghijklmnopqrstuvwxyz
  vm01:
    name: vm01
    role: vm
    mode: vm
    is_web_interface: false
    persistent_storage: true
    vm:
      memory: 1
      storage: 10
      vcpu: 1
      os: ubuntu
      os_version: 22.04
proxy:
  use_ssl: true
  domain: app-deploy-demo.domain.tld
  backends: ["web01", "web02"]
vpn:
  use: tailscale
  auth_key: tskey-auth-....
  expose_lan: true
  accept_dns: true

New Changes:
- Support for multiple backends per frontend domain
- scale: option is available but disabled during beta.
- Automatic load balancing and health checks are issued to backends. Backends which become unhealthy are removed from the pool of available backends until they become healthy again.
- New restart-container endpoint is available.
- Automated monitoring system will attempt to restart containers and VMs which become unhealthy. If unsuccessful after 5 attempts, monitoring system will send alerts to the portal and remove the container from rotation automatically.

SilverCreek

New Feature: Deployments from Git now support a branch directive. You can pull from a branch instead of the main branch.

New Endpoint: The logs of your deployment are now available at GET /app/get-deploy-logs. Logs are available for 24 hours before they are removed automatically.

SilverCreek

Apologies for the delay in updates here, I have been away (and still partially am).

New Features:

• Storage Backends now supported.
• Shared Storage between containers, on same-region deployments, are now able to be shared including cross-hypervisor (internal: Gluster + Ceph support).
• API is now standardized with response formatting.
• New endpoints for Container Logs, Container Power, VM Power, Deployment Logs.
• Rapid Deployment with Autodiscover Mode (internal: autodiscover-backend).
• Git Deployer: You can specify public_repo: true, no longer requires authentication to pull from Git.
• SFTP: SFTP now exposes all your local volumes for regional containers, including shared storage, and deployment files.
• Tailscale Refined: Faster deployment, better output logging in deployment logs.
• CLI: Version 0.1 of our official CLI is now released, beta users please contact for a copy of it.

New Regions:

We have added multiple new regions and availability zones (AZs) to the beta, with 6 more on the way.

• 3x new QC Availability Zones (Montreal and surrounding areas)
• 1x France Availability Zone (1 more is planned)
• 1x Kansas City Availability Zone (1 more is planned)

Coming soon:

• 2x Sydney, AU Availability Zones (SYD1, SYD2)
• 2x Auckland, NZ Availability Zones (AUK1, AUK2)
• 1x Germany Availability Zone (1 more is planned down the road)
• 1x Nevada Availability Zone (1 more is planned down the road)
• 2x Amsterdam Availability Zones
• 2x Vancouver Availability Zones