Winding Down Darklang-Classic
Darklang-Classic has been running in production since 2019, first in a private beta for a few users/orgs, and eventually a public beta since then.
Back when it was first deployed, the company supporting the product was in a fast-expansion ok-to-spend-VC-money phase, with vendors giving discounts to the org. Those discounts eventually died out, along with VC money.
As Dark Inc. ran out of money and we've begun building Darklang Inc. to continue development, we've made the decision to transition Darklang-Classic to a limited-user model, shutting down inactive canvases after a brownout phase.
Why We're Making This Change
As we set up the new company and purchased the old IP, we hoped to keep Darklang-Classic running without change.
However, the reality is that -Classic costs ~$2600/month to run (split between Google Cloud, monitoring tools, and various services), and as a new company with limited runway, we need to focus our resources on building the next iteration of Darklang rather than maintaining legacy infrastructure.
We spent some weeks exploring cost-cutting measures, but what started as "just scale back some services" quickly became exactly the kind of DevOps-heavy work we're building Darklang to escape, and our efforts weren't getting us far. Beyond financials, -Classic hasn't received real feature updates in over two years, yet we find ourselves distracted, maintaining this quiet product - our energy is better spent on the new platform that will serve you better long-term.
Continued Support for Active Canvases
Existing users with active canvases will be entirely unaffected by these changes. Just send us an email to classic@darklang.com with a list of canvases you'd like us to keep alive. If you forget the names of your canvases, log in, hit 'Settings' and view your list of canvases there.
It's been genuinely rewarding to support Darklang-Classic users over the past few years - from those building real projects to everyone who's experimented with the platform. We'd never want to shut down something people are actively using, which is why we're committed to working with anyone who wants to keep their canvas running - whether through our hosted option for a while longer, or helping with self-hosting solutions.
Transition Timeline
In 30 days (July 16th), we'll start a phased brownout of Darklang-Classic, for anyone who doesn't email us to opt-in to having their canvases kept around.
During the brownout we'll intermittently disable services (HTTP handlers, cron jobs, queues, etc.) to flush out any remaining active users and hear from folks who want to stay online. First we'll turn things off for an hour, then for a few hours, etc. We expect this will take around a week in total.
After the brownout is complete and we have confidence that everyone is set, we'll do a one-time export, store those for safe-keeping, before deleting the user data. (If someone's currently offline for months, we'd still like them to have some path forward.)
Finally. Cost-Savings and Less Distraction
After the brownout and shutdown is done, everything should be much cheaper for us. With far fewer canvases, we'll just see a lot less traffic across the board - in GCP, and throughout our vendors. When that's settled, we can drastically downgrade our plans with these various vendors.
Between GCP usage and downgrading our vendor plans, we're anticipating our monthly costs lowering from ~$2600/mo to ~$500/mo.
Open-Source
While Darklang has been source-available for a long time, we've just open-sourced all of our GitHub repos, along with this announcement – see details in the adjacent post. If you're interested, see the dark-classic repo for the bulk of the bits. Separate repos dark-classic-dockerfile and dark-ocaml are also around, supporting various bits of development.
If you want to play around with the code, I'd recommend cloning the dark-classic repo, and just running it in VS Code. The README should have enough info for you to get started, editing a canvas in the UI locally.
Self-Hosting Support
Being open source doesn't mean it's easy to just deploy it all and self-host your existing canvases. Darklang runs on a number of vendors, and our CI/CD scripts are all written assuming our hosting setup. It's definitely possible to fork the codebase such that it could be more easily self-hostable, but it'd take some work.
We've created a new GitHub Issue to coordinate community efforts around making -Classic more self-hostable. Initial thoughts, technical approaches, and ongoing discussion will happen there.
What happens long-term?
Since users who want to keep their canvases will email us directly, we'll use that as an opportunity to connect with them. We'll learn what they're using -Classic for, identify systems we can safely disable to save additional costs, and set expectations about our ability to handle production issues. If you email us with your canvas names in the next few weeks, you shouldn't be impacted at all for at least the next several months.
We expect to keep -Classic running in this limited "just-a-few-users" mode through 2025, covering the costs as a thank-you to our early users. Beyond that, we'll do our best to provide a clear migration path to the new version of Darklang once it's stable.
Looking Forward
I've used Darklang-Classic for personal use cases, use cases at my previous employment, and internal uses at Dark Inc. When it fit the needs, it was lovely. I'm looking forward to getting the new iteration of Darklang to a point where I'm using it all day, every day, powering my life of software.
We're incredibly grateful to everyone who used Darklang-Classic, and we really appreciate your understanding as we navigate this transition to build something more sustainable. Thank you for being part of this journey - from those who built real projects to everyone who experimented with the platform. We'd love to hear from you about what you liked and didn't like in -Classic, as it helps inform what we're building next.
Comment on Hacker News, Twitter, Mastodon, Lobste.rs, LinkedIn