pitr.ca

Solving LinkedIn Queens with APL

2025-06-14T00:00:00+00:00

Solving LinkedIn Queens with APL

14 Jun 2025 on Peter Vernigorov’s blog

A couple months ago I noticed that LinkedIn now has a few simple games. They’re not much to write home about, but I really enjoy playing Queens.

This week I saw two posts about solving the Queens game programmatically. Both were quite interesting to me, so I thought this was a good opportunity to also solve the game in my favourite language - APL - and share my experience. Having been using APL for Advent of Code, I wanted to share my passion for it with others.

Rules

The game is pretty straightforward: each colored region must have exactly one queen, and two queens cannot occupy the same row, column, or be adjacent. Multiple queens may share diagonals as long as they’re separated by at least one space.

Board

First, let’s choose a data structure. LinkedIn sends the initial state as a list of rows, assigning each color a number. We will use 0 to mark queens. Let’s create a 2‑dimensional board representing the image:

b←⍉⍪1 1 1 1 1 1 1 1
b⍪← 1 1 2 2 2 2 3 1
b⍪← 1 1 2 4 4 2 3 1
b⍪← 1 1 4 4 4 2 3 3
b⍪← 1 5 5 4 2 2 3 3
b⍪← 1 5 6 6 2 7 7 3
b⍪← 5 5 6 6 6 6 7 7
b⍪← 5 5 5 6 8 6 6 7

And print it, by assigning it to the screen represented by a box:

⎕ ← b

1 1 1 1 1 1 1
1 2 2 2 2 3 1
1 2 4 4 2 3 1
1 4 4 4 2 3 3
5 5 4 2 2 3 3
5 6 6 2 7 7 3
5 6 6 6 6 7 7
5 5 6 8 6 6 7

Breadth-first Search

Next, algorithm choice: depth-first vs breadth-first search. While depth-first is a somewhat obvious choice (and works beautifully for N‑Queens, as seen in this video), I chose breadth-first search, inspired by a Sudoku solution video I love.

In our case, the search tree depth equals the number of colors. Each step expands the current solution space by enumerating valid queen positions for a new color. Here’s a simplified mock-up (color order is chosen strategically):

initial state
2 2 2 2
4 3 2 3
4 3 3 3
3 3 5 5
3 3 3 3

place all allowed queens for color 5
2 2 2 2   1 2 2 2 2
4 3 2 3   3 4 3 2 3
4 3 3 3   3 4 3 3 3
3 3 ♕ 5   3 3 3 5 ♕
3 3 3 3   3 3 3 3 3

place all allowed queens for color 4
2 2 2 2   1 2 2 2 2   1 2 2 2 2   1 2 2 2 2
♕ 3 2 3   3 4 3 2 3   3 ♕ 3 2 3   3 4 3 2 3
4 3 3 3   3 ♕ 3 3 3   3 4 3 3 3   3 ♕ 3 3 3
3 3 ♕ 5   3 3 3 ♕ 5   3 3 3 5 ♕   3 3 3 5 ♕
3 3 3 3   3 3 3 3 3   3 3 3 3 3   3 3 3 3 3

place all allowed queens for color 1
notice that solution space is shrinking as some positions are invalid
 ♕ 2 2 2 2   ♕ 2 2 2 2
4 3 2 3   3 4 3 2 3
♕ 3 3 3   3 ♕ 3 3 3
3 3 ♕ 5   3 3 3 5 ♕
3 3 3 3   3 3 3 3 3

place all allowed queens for color 2, at this point only a single board is valid
 ♕ 2 2 2 2
4 3 ♕ 3
♕ 3 3 3
3 3 5 ♕
3 3 3 3

place all allowed queens for the last color 3
 ♕ 2 2 2 2
4 3 ♕ 3
♕ 3 3 3
3 3 5 ♕
3 ♕ 3 3

Let’s imagine we created an infix function fills that takes a color and current solution space, and produces a new solution space. We start with the board as an initial solution space, and fill color 5 with 5 fills b. Since APL is executed right-to-left, we can then fill color 4 with 4 fills 5 fills b. And so forth… the whole solution would be the result of 3 fills 2 fills 1 fills 4 fills 5 fills b.

For those familiar with functional programming, this will look like a use case for a fold, specifically foldr (right fold). In APL this is such a common operation that it is shortened to a single symbol - /. The above becomes fills / 3 2 1 4 5 b.

So far, we’ve been designing the solution using mock output and pseudo code. However, the top-level function for our actual solution will look very similar to the code we used, by first building that list and then folding it. In fact, here it is:

solve ← {0=⊃fills/(∪,⍵),⊂⊂⍵}

Let’s see how it works when built up slowly. Comments start with ⍝ symbol (a light bulb).

⍝ an anonymous function that just returns the argument
⍝ ⍵ is a symbol for the right argument
⎕ ← {⍵} b
 1 2 2 2 2
 3 4 3 2 3
 3 4 3 3 3
 3 3 3 5 5
 3 3 3 3 3

⍝ flatten the board
⎕ ← {,⍵} b
 1 2 2 2 2 3 4 3 2 3 3 4 3 3 3 3 3 3 5 5 3 3 3 3 3

⍝ unique list of colors
⎕ ← {∪,⍵} b
 1 2 3 4 5

⍝ board again
⎕ ← {⍵} b
 1 2 2 2 2
 3 4 3 2 3
 3 4 3 3 3
 3 3 3 5 5
 3 3 3 3 3

⍝ enclosed twice, making a solution space with one boxed element
⎕ ← {⊂⊂⍵} b
   1 2 2 2 2
   3 4 3 2 3
   3 4 3 3 3
   3 3 3 5 5
   3 3 3 3 3

⍝ all together now, create a list that we will fold over as explained earlier
⎕ ← {(∪,⍵),⊂⊂⍵} b
 1 2 3 4 5  1 2 2 2 2
            3 4 3 2 3
            3 4 3 3 3
            3 3 3 5 5
            3 3 3 3 3

⍝ actually fold using our fills function
⎕ ← {fills / (∪,⍵),⊂⊂⍵} b
   0 2 2 2 2
   3 4 3 0 3
   3 0 3 3 3
   3 3 3 5 0
   3 3 0 3 3

⍝ disclose twice
⎕ ← {⊃⊃fills/(∪,⍵),⊂⊂⍵} b
 0 2 2 2 2
 3 4 3 0 3
 3 0 3 3 3
 3 3 3 5 0
 3 3 0 3 3

⍝ pretty print the result
⎕ ← {'♕1234'[⍵]} {0=⊃⊃fills/(∪,⍵),⊂⊂⍵} b
 ♕ 2 2 2 2
 3 4 3 ♕ 3
 3 ♕ 3 3 3
 3 3 3 5 ♕
 3 3 ♕ 3 3

Helpers

Now we are ready to actually implement the fills function. But first let’s define some helpers.

The first helper is a place function that places a 0 (queen) on the board. It’s called like this: 1 2 place b. We will use an At operator, represented by symbol @:

⍝ ⍺ is the left argument
place ← {0@(⊂⍺)⊢⍵}

⎕ ← 5 5⍴1
1 1 1 1
1 1 1 1
1 1 1 1
1 1 1 1
1 1 1 1

⎕ ← 1 2 place 5 5⍴1
1 1 1 1
1 0 1 1
1 1 1 1
1 1 1 1
1 1 1 1

Easy enough!

Note: APL allows overriding index origin. The default is 1-based; however, the place function doesn’t work there for surprisingly complicated reasons - it involved the behaviour of Each with empty lists, prototypes, and @ primitive failing when asked to update index (0,0) in 1-based origin system. So this function assumes that the origin is setup with ⎕IO ← 0. The rest of the code doesn’t care about index origin.

Now, let’s build the function - we will call it avl - that returns valid queen positions for a specific color. We will call it with color and board as such - 4 avl b:

avl ← {
    ⍝ find positions of all existing queens
    q ← ⍸0=⍵

    ⍝ find positions of a particular color
    p ← ⍸⍺=⍵

    ⍝ boolean mask over p that have row or column conflict with any existing queen
    rc ← ∨⌿1∊¨q∘.=p

    ⍝ boolean mask over p that are next to any existing queen
    nx ← ∨⌿∧/¨1≥|q∘.-p

    ⍝ select color positions that are covered by neither mask using a Nor.
    ⍝ here slash symbol is a select, not fold
    (rc⍱nx)/p
}

Last line in this function implicitly returns the result - list of legal positions for a queen in the color region. I leave deeper understanding of this function as an exercise to the reader. For those unfamiliar with APL primitives, APL Wiki has great pages for each, such as ⍸ - indices function.

And now we are ready to implement the fills function. We will split it into two functions - fills that works on a solution space and fill that works on a single instance of a board. Left argument for both is always the color.

⍝ places a queen on each available position of a board
fill ← {(⍺ avl ⍵) place¨ ⊂⍵}

⍝ calls fill for each board, then merged the results
fills ← {⊃,/⍺ fill¨ ⍵}

And that’s it!

Full Solution

The whole solution is this:

place ← {0@(⊂⍺)⊢⍵}
avl ← {
    q ← ⍸0=⍵
    p ← ⍸⍺=⍵
    rc ← ∨⌿1∊¨q∘.=p
    nx ← ∨⌿∧/¨1≥|q∘.-p
    (rc⍱nx)/p
}
fill ← {(⍺ avl ⍵) place¨ ⊂⍵}
fills ← {⊃,/⍺ fill¨ ⍵}
solve ← {⊃⊃fills/(∪,⍵),⊂⊂⍵}

11 lines of code that have zero external dependencies, not even APL’s built-in libraries. Just the primitives. avl can be minified to much fewer lines, but I see no reason to do that.

There are heuristics that could be used, such as ordering colors by number of positions (fill smaller regions first). However, the current solution runs in a few milliseconds already. Still, there might be edge case boards where this solution doesn’t perform well, but I do not have many data points.

Let’s solve the large example:

⎕ ← board
 1 1 1 1 1 1 1 1
 1 1 2 2 2 2 3 1
 1 1 2 4 4 2 3 1
 1 1 4 4 4 2 3 3
 1 5 5 4 2 2 3 3
 1 5 6 6 2 7 7 3
 5 5 6 6 6 6 7 7
 5 5 5 6 8 6 6 7

⎕ ← {'♕.'[×⍵]} solve board
 ♕.......
 .....♕..
 ...♕....
 .......♕
 .♕......
 ......♕.
 ..♕.....
 ....♕...

The End

My hope is that this has piqued your interest in APL, at least from the perspective of expanding your programming toolbox. APL is a very powerful language that allows you to express complex algorithms in a very concise way. If you want to learn more, I recommend checking out APL Wiki and TryAPL.

Discussion: lobste.rs news.ycombinator.com

Contributing to Gemini ecosystem

2021-05-29T00:00:00+00:00

Contributing to Gemini ecosystem

29 May 2021 on Peter Vernigorov’s blog

About a year ago I found out about Gemini protocol. For those who aren’t familiar with it, it’s a new Internet protocol (which together with its accompanying gemtext format) aims to build an alternative “web, stripped right back to its essence”. It appealed to my love for minimalism and I built a few things for its ecosystem.

Regardless of your views of Gemini, or familiarity, the greater lesson here is that even with a simple protocol, useful programs almost never are. Similar messages are echoed by others such as Text Editing Hates You Too (2019).

This post requires no knowledge of Gemini protocol specifications. Each section focuses on one project, explaining why and how it was built. Feel free to skip “How” sections as it can go deep into technical details.

iOS Browser

What Elaho is a fully featured iOS browser with features people are used to, such as tabs, bookmarks, history, etc. This is the first project I worked on. While mostly a backend engineer by trade, I’ve delved into the client side of things quite a few times. But this was my first published iOS app.

Why At the time, most clients for Gemini were terminal based, with only one or two focusing on Desktop GUI. I realized that more so than the web, Gemini is almost exclusively meant for consuming content. There is only one way to send information from the client, using something not unlike a one textbox form. Today, around 60% of content consumers online are on mobile/tablet devices, and it’s growing with every year [source]. Within those, while Android has a larger market share than iOS, I’ve chosen the latter as I have the most experience with it.

How Currently, Gemini-specific code accounts for 2% (1k of 41k) of lines of code. This includes Gemini protocol, certificate helpers, gemtext rendering and ansi escape codes. Most of the other code deals with UI for features such as tabs, session restoration, bookmarks, share extension etc. Foreseeing this, I decided to use an existing browser that already has most of this functionality included - Firefox for iOS. It is licensed under Mozilla Public License 2.0, which allows me to fork it as long as copyright and license notices are preserved. Of interest is my first commit, which removed 30k lines worth of telemetry/tracking code: Adjust, Leanplum, Sentry.

Most of the code is responsible for UI. While I could benefit from view layer code responsible for managing bookmarks, history, and others, the underlying storage layer which relied on Rust-based Firefox Application Services had to be replaced with Realm.

Other mobile browsers for Gemini took a different route. Ariane and Phaedra target Android devices, Deedum uses Flutter framework, Rocketeer used SwiftUI, and Lagrange is built on a custom-made cross-platform framework written in C. All were built from scratch and (apart from Lagrange, author of which has put in an impressive amount of time into the project) do not support most browser features expected by users. Examples include things like session restoration, URL bar with autocomplete, custom keyboard and without spell check, and horizontal slide gesture to go back/forward. The reason is that the sheer amount of work needed to build all of this auxiliary functionality seems to result in most of these projects being abandoned by their authors.

Result Since it’s been in the app store, I’ve seen about 20 weekly installs, and after releasing a new version I get about 3000 updates. It has been mentioned on AppleVis (online resource for blind and low vision users of Apple products).

Server Framework

What Gig is a Gemini framework written in Go that helps quickly build dynamic Gemini servers. It is very similar to Gin, Echo and other projects for HTTP servers.

Why At the time, apart from a couple capsules online (search engine and a gardening experience game), all resources were static. Most servers at the time (and this is still true as of 2021) only supported serving static files. I had a few ideas for dynamic resources (see other projects below) and a simple framework would minimize work required later.

How Borrowing from other Go frameworks, this project has a zero-allocation router, extensive documentation, lots of rendering helpers, a few builtin middlewares such as Logger, Recover, ValidateHasCertificate and support for custom ones. While HTTP frameworks can rely on net/http package, Gig needed to implement Gemini protocol specification. Each route handler gets a Context (an interface containing request/response helpers) similar to Gin and Echo, and after the request is done the Context is later reused thanks to sync.Pool.

As I used it to build other projects, I was able to iterate on the framework itself. Context interface was improved, helpers to return an error to client were simplified, a middleware for login/password authentication was added.

Result In the beginning Gig was primarily used by me. However, in the last few months a number of servers came up that imported it (see Who uses Gig). I even found a live stream on YouTube that features Gig being used to build a microblogging app.

Link Aggregator

What Geddit is similar to Hacker News, Reddit.

Why In late 2020 new capsules were popping up weekly if not daily, and some were usually posted to the mailing list. These emails were in-between other discussion threads, such as protocol finalization, protocol ideas, questions, etc. I came to a conclusion that a different mechanism to discover and share new capsules/pages was needed. Link aggregation services work relatively well for this in my experience, so I set out to build one for Gemini.

How Thanks to Gig, it was quite simple to build using ModelViewController pattern. Controller layer, including CRUD for posts and comments, contains about 155 sloc. Model layer, built on GORM+SQLite, is another 100 sloc. Views use text/template format. The project compiles into a small static binary that can be rsync’ed to the server.

Result As of May 2021 there were 160 links submitted and 250 comments posted. There are at least a few submissions a week, and it has been mentioned on the mailing list many times. I continue to check it myself every few days. Other similar aggregators and forum-like capsules went live but none have maintained a consistent usage by the community.

Wikipedia Proxy

What An interface to Wikipedia from Gemini, available at gemini://wp.glv.one.

Why Capsules are usually built around content and functionality. Most content is produced by authors, with blogs as a prime example. However, there is a lot of content already available elsewhere on the Internet, and Gemini could be a good interface to consume it. Wikipedia content is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported License and it can be remixed (in this case, converted to Gemini text) and shared (distributed at wp.glv.one). Gemtext format is a simplified version of Markdown, so the challenge would be to simplify an already content-rich format. Another challenge is to parse the Wikitext format.

How Backend is built on my Gig framework, go-mwclient for Wikipedia client, and github.com/d4l3k/wikigopher/wikitext for Wikitext parsing.

Wikitext package is part of a similar project for gopher space. It contains a PEG grammar and a parser. It was extremely easy to incorporate this into my project. Once an AST (Abstract Syntax Tree) is generated, my code walks the tree and generates Gemtext.

The first challenge was links in text. Gemtext allows text OR link per line, but not both. Wikipedia articles usually contain a LOT of inline links to related articles so it’s important that these links are kept close to the text. The solution I came up with was to list all links directly AFTER the paragraph, by remembering links as they are parsed and storing them in a Links structure. Once a paragraph break was detected, it was a matter of simply flushing those links and resetting.

type Links struct {
    buf strings.Builder
}

func NewLinks() *Links {
    return &Links{}
}

func (f *Links) Add(name, href string) {
    f.buf.WriteString(fmt.Sprintf("=> %s %s\n", href, name))
}

func (f *Links) String() string {
    return f.buf.String()
}

func (f *Links) Reset() {
    f.buf.Reset()
}

Anything that is not a paragraph, heading text, list or link is skipped. This includes footnotes, tables, images, complex structures like {Infobox}, etc.

Result While there is an active usage of it, I consider this project a failure. Simply looking at the amount of content that is skipped due to inability to represent it in Gemtext format renders it quite useless.

But perhaps the bigger reason for its failure is the performance factor. This app constantly uses most of the memory and cpu on my server, which profiling showed is due to the parsing library. Latency is also quite large, especially for large pages, again due to slow parsing. Most articles take from a few seconds to more than a minute to load. There are quite a few Wikitext parsers, but unfortunately none that are written in Go.

Another Wikipedia Proxy project by Alex Schroeder hosted at gemini://vault.transjovian.org/. It is built in Perl and uses a lot of regular expressions to convert Wikitext to Gemtext. In the end its latency is quite good.

On a related note, a few other proxy capsules have come up for resources like Reddit, Hacker News, and newspapers such as Guardian, Deutsche Welle, CNN, NPR. Much of this content is licensed less permissively, and I think it does more damage than good to the Gemini community.

PaaS

What glv.one is a Platform-as-a-Service, similar to Heroku. Deployment is done by pushing a new docker image to a private registry, and the administration interface is available over Gemini at gemini://glv.one.

Why Having built a few capsules using Gin, I wanted to be able to quickly create new ones. Deploying a new capsule with glv.one is as easy as clicking “New” in the admin interface, and then pushing the image to deploy.glv.one/$USER/$APP. I also saw a potential need in the community to have a place to publish dynamic capsules without paying for your own server. Free static hosting is offered by many capsules such as gemini.circumlunar.space, flounder.online, gemlog.blue and srht.site, but there was no place to host dynamic content.

How This is the only project that I did not open source, mostly because there isn’t much to open source. It is built by glueing different parts together.

Docker images are pushed to a private Docker Registry. Only requests from docker login and docker push are allowed. Registry is password protected with htpasswd, and has a webhook setup to notify a little Go server of pushes:
```
auth:
  htpasswd:
    path: /.htpasswd
notifications:
  events:
    includereferences: true
  endpoints:
    - url: http://172.17.0.1:8080/event
      ignore:
        actions:
          - pull
```
The tiny Go server parses the webhook event, makes sure that the $USER pushed the new image to /$USER/$APP, an app that he owns. Then it runs docker stop $APP && docker rm $APP (to stop the previous version), and docker run -d --restart=always --name $APP $IMAGE. There are a few more arguments to limit cpu/memory resources and to mount a volume.
Each app gets its own local port, which is mapped to port 1965 in the container.

Nginx runs on port 1965 and streams requests to the correct capsule’s port based on the request’s SNI (Server Name Indication):

stream {
  map $ssl_preread_server_name $upstream {
    include /etc/nginx/stream.d/*.conf;
  }

  server {
    listen      1965;
    proxy_pass  $upstream;
    ssl_preread on;
  }
}

When creating a new app, it simply needs to write "$APP.glv.one" 127.0.0.1:$PORT; to a file in /etc/nginx/stream.d/ and request nginx to reload its configurations.
Admin interface offers additional functionality such as viewing logs (by sending back docker logs $APP) and deploying an old version (by sending a fake push event with that image ID).

Result While there was no community adoption (every new user must be manually whitelisted by emailing me, I received 0 emails), I have used GLV.One for all my apps. Despite being quite hacky (and probably not secure), it works surprisingly well.

Summary

There were a few smaller projects I built in the Gemini universe that I won’t go into, as this article is long enough. Overall I enjoyed being part of the community and building projects that try to solve real problems.

Discussion: lobste.rs

Spot instances for personal servers

2021-05-23T00:00:00+00:00

Spot instances for personal servers

23 May 2021 on Peter Vernigorov’s blog

2023 Update

I have since moved from AWS to Hetzner as it is significantly cheaper than spot instances on AWS, at least for the workload that I have. 2 instances (t3.nano and t3.medium) with an EBS volumes were replaced by a single CAX11 (2x arm64, 4GB RAM).

Summary

Use spot instances for personal projects to save ~70% costs, and spot.io to ensure their stability.

Why?

There was a recent post on lobste.rs asking “What are you self hosting?” and while some people prefer to host as little as possible relying on various services, many are running their own servers.

There are quite a few cheap/free options for compute instances. Some are listed here. However, if one would like to stay on AWS, beyond 1 year of free 750 hours/month of micro instances, there isn’t much that can be done to save costs.

In this post I describe my setup, that keeps the costs and maintenance as low as possible.

Minimize complexity

While orchestration systems like Kubernetes can and do simplify the workflow, thereby improving delivery time and other KPIs, they come at a cost.

My employer has been an early adopter of Kubernetes, and now it is as easy to deploy a service as simply pushing to a branch. But it comes at non-zero maintenance costs. There are multiple teams responsible for maintaining and updating Kubernetes clusters, running CI/CD tools, documenting best practices, supporting teams in their work, etc. See a good write up here.

For a personal project, unless the goal is to acquire experience with Kubernetes, it is usually a huge overkill both in terms of overhead and maintenance costs.

I run Amazon Linux 2 distributions, heavily utilizing systemd to run everything.

Spot

Every personal server I have runs on a spot instance.

Spot instances are unstable by design, and can go down any time. However, in practice I have seen very few terminations. My longest uptime has been above 300 days (in region eu-west-1), and the majority of interruptions was me restarting them for various reasons.

Running on spot trains one to expect terminations. After all, any instance, be it spot, on-demand, or even a server in your house, can be restarted or terminated at any time.

Additional benefit of being prepared for terminations is to be able to run instances only when needed. I have a beefy instance dedicated to hosting a Minecraft server, and it’s only up when I need it. If I forget to turn it off, it automatically goes down at midnight.

This is where spot.io comes in. They help manage spot instances by foreseeing terminations based on spot market shortages, shutting the instance down safely, finding an instance type and an availability zone with better score, and starting your instance up again. They can manage 20 instances for free, which is enough for most people.

Each instance type in every availability zone gets a score. In case of a termination, spot.io will use a better scoring instance/AZ to boot the instance back up. I use t(2,3,3a).(micro,small) instances. In case of low scores across all instance types/AZs, there is an option to automatically go to on-demand until spot market improves.

In my experience, instance recycling takes about 5 minutes, which even with a daily termination would be sufficient for most personal project.

Root Volume persistence

The killer feature for me is root volume persistence. My instances do not have any additional storage apart from the root EBS volume, which contains OS, all packages, and my applications. Usually, the root volume is deleted on termination, but spot.io creates an AMI from the root volume. So next time my instance boots up using that AMI, it will have all the same content.

Public IP

There are two options for instance’s public IP. For always on instances I use Elastic IP, which is free as long as the IP is attached to an running instance. And for instances that I only bring up when needed, I use an auto-assigned IP with a simple startup script that updates DNS. For Cloudflare I use the following:

/home/ec2-user/update-dns.sh (replace ZONE_ID, DNS_ID and API_TOKEN with correct values from the dashboard)

#!/bin/bash

IP=$(curl -s "http://169.254.169.254/latest/meta-data/public-ipv4/")

curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$DNS_ID" \
  -H "Authorization: Bearer $API_TOKEN" -H "Content-Type:application/json" \
  -d "$(cat <<EOF
{"content":"$IP"}
EOF
)"

/usr/lib/systemd/system/update-dns.service

[Unit]
After=network.service

[Service]
ExecStart=/home/ec2-user/update-dns.sh
User=ec2-user
Group=ec2-user

[Install]
WantedBy=default.target

Non-24x7 instances

For managing instances that are up only when needed, I have 2 shell functions:

# Fish shell syntax, but can be easily changed to support bash/zsh

function spotstart
  curl -X PUT -s \
  -H "Authorization: Bearer $API_TOKEN" \
  "https://api.spotinst.io/aws/ec2/managedInstance/smi-$INSTANCE/resume?accountId=act-$ACCOUNT_ID"
end

function spotstop
  curl -X PUT -s \
  -H "Authorization: Bearer $API_TOKEN" \
  "https://api.spotinst.io/aws/ec2/managedInstance/smi-$INSTANCE/pause?accountId=act-$ACCOUNT_ID"
end

Alternatively, instance can be setup to be up only during specific days/hours:

Fine print

I am not affiliated, associated, authorized, endorsed by, or in any way officially connected with spot.io, apart from using their services.

There are small additional costs associated with using spot.io:

CloudWatch - spot.io collects data about the health of an instance using CloudWatch, and those API requests add up. With 2 instances, over a month I see about 6 thousand API requests (which are below the 1 million free requests) and 200 thousand metrics requested using GetMetricData API, which costs about $2/month.
EBS snapshots - spot.io periodically creates a snapshot of EBS root volumes, which ends up costing additional ~50% of their normal cost. For 2 8GB root volumes this ends up being ~$0.87 in my region.

As can be seen, this is nowhere near close to savings from one instance alone, but worth being aware of.

Discussion: lobste.rs