hey everyone. i owe you a real explanation of what's been going on over the last few weeks, because it's been a lot, and you deserve to know where things stand.

the short version: we had a rough downtime that uncovered some serious underlying problems, things got worse before they got better, and (in the middle of all of it) we made some big moves that i actually feel good about. here's the whole story.

what happened during the downtime

two weeks ago i took the sites down for a scheduled maintenance window. it was short notice, i know, and i'm sorry about that. the work took longer than the overnight window i'd planned for, so we came back up before it was finished. we limped along for about two weeks. things were mostly working, but not great.

eventually i had to make the call to take everything down again to actually finish the job. that's when things got worse.

it turned out that for those two weeks we were running with corrupted data in the database (which also means that corruption was sitting in our backups). the worst of it was some custom wearable information: prices, passwords, how many have been sold. we've recovered most of it, but some of those details are going to need to be pieced back together over the next few weeks. i'll keep you updated as that process continues. if something looks off with your custom wearables, please let me know.

i'm sorry. this sucked and i know it.

the pivot to kumos

here's where things get more interesting. when survival started and i had to figure out what to do with this extended downtime, i made a call: let's use this moment to move more of the infrastructure over to kumos.

so that's what we did. the cron system (shops restocking, all of that) is now running on the kumos backend. survival features (kissing, biting, strain progression) are running on kumos too, regardless of whether you're using the legacy wardrobe. and avatar image generation is now going entirely through kumos.

this might sound like a lot to do during a crisis, but it actually made sense. kumos is built on a powerful modern framework, and once you have the basic plumbing in place, adding features is fast. avatar generation came with real caching and opens up some genuinely fun new things we can do with avatars. new wardrobe features that would have taken weeks before took hours.

why kumos, and why now?

i've been asked this a lot and i want to be honest about it.

legacy subeta was running on PHP 7. PHP 7 has been out of support for years. getting security updates at this point requires bringing in outside contractors, which is expensive and not sustainable. and as time goes on, modern tools and libraries just... stop working with it. it's not fun to want to build something and not be able to because the foundation is too old.

a few years ago i got a quote from a team to bring subeta up to current standards. it was going to be six months of work and tens of thousands of dollars. it felt smarter (and more exciting) to build something new and move to it thoughtfully. that's been the plan with kumos.

but here's the thing i'm really excited to tell you: legacy subeta is now running on PHP 8.4.

a note on what subeta actually is in 2026

i want to be real with you about something, because i think it matters for how you think about all of this.

subeta is over 20 years old. at one point it was a real company with a real team. and i think some part of everyone's brain (including mine sometimes) still expects it to operate like that. but it doesn't, and it can't.

i'm the only programmer working on subeta. we have a small team, and i genuinely believe we have some of the best illustrators and support staff in this whole corner of the internet. but it is a very small operation. virtual pet sites just don't generate the kind of revenue that funds engineering teams. that's the reality of this type of site in 2026.

so when you're deciding whether to grab a subscription: that's what you're supporting. a scrappy small team doing the best we can with what we've got. the site has always been a little scrappy, and honestly it probably always will be. i think that's okay. i'm proud of what we build with the resources we have.

toot toot on my own horn for a second: i think i'm a pretty world class programmer, and that goes a long way. but there's still only one of me.

what we actually did to legacy

this is the part that took the most work during the downtime. we did a large-scale refactor of the legacy codebase. took out huge chunks of old code, modernized a lot of what was left.

this kind of work used to be brutal. but doing large codebase migrations is genuinely easier now with machine learning tools (not even generative AI, older methods that can make intelligent, systematic changes across thousands of files at once). it's the difference between "manually rewrite every file" and "describe the transformation and run it." it's not magic and it's not perfect, but it gave legacy subeta a much longer shelf life than it had two weeks ago.

you might notice things looking slightly different. i was able to pull out years of accumulated CSS that wasn't really doing anything (and that's a good thing!) but it might mean some user and pet profiles look a little off. i'm working on a shim to make sure that impact is minimal. if something looks really broken, let me know.

to give you a sense of what working in legacy is actually like: there were over 400 places in the codebase that set the font-size on a particular page, all cascading off each other. four hundred. that's the kind of thing you're dealing with when a codebase is 20+ years old and has had dozens of hands in it. cleaning that up is painstaking, but we're doing it.

here's a good example of what's now possible: i updated the /pets page and was able to strip out years of bootstrap and stacked stylesheets, replacing all of it with modern CSS (flex and grid) to make a clean, simple layout. it looks great and the code behind it is actually readable. that kind of thing used to be basically impossible to do safely. now it's not.

where does this leave us?

honestly, in a better spot than before the downtime, even if it was a rough road to get here.

the immediate plan:

• i'm porting some of the kumos-only features back to legacy, because it can now actually support them
• i've got a list of things i've wanted to fix forever, and i'm going to work through it
• i'm easing off the "everyone needs to move to kumos right now" energy for at least the next week while i make sure everything is stable and running well

thanks for sticking with us through this. more updates soon.

• keith

Admittedly PHP has gotten much better in the last ~10 (omg i've been doing this way too long) years! Much better typing systems!

I totally hear you! Many of the changes had to be made quickly, to do that upgrade that i mentioned, so I'll be smoothing them out over the next few days. The quick stock changed pretty fast!

The auto pricer was the very last piece of the site relying on a specific piece of technology - and so it also had to go. I'll make the page more clear, that's great feedback ❤

Hi, I absolutely hear you . I am also very unhappy with the performance on Legacy and on Kumos right now. There have been points where both of them have been under one second loading. There have been points where Kumos has been under one second loading.

A part of what the downtime was, was moving to a new provider. And what I'm finding with our new hosting provider is that the connection between our web servers and our database isn't what I expected and is a little bit slower. And on Legacy especially, every single page makes hundreds of database requests. And these are round trip. They go to the database and then they come back. Each of those on our new setup has 30 to 50 milliseconds of additional time added on top of them, which in the case of hundreds of queries, really, really adds up.

So now that we're stable and loading, I am working on getting the speed up back to where we were before, and it could very well be the case that this provider just isn't going to work out for the type of workload that Subeta has. I did due diligence beforehand and talked to them, and it seemed like it was going to be a good fit, but this is the sort of thing that you really can't know until you have live traffic doing the requests. So I'm trying to resolve the situation on our end and make it faster, but I'm also looking at what our other options are.

Can you tell me where the text is tiny? I don't have that issue.

thank you!! I don't see that, I'm in firefox so I think this is probably a browser issue. I'm gonna download and see if I can resolve, thank you for the screenshots!

Also you can drag (or upload!) images on legacy now (which is why the boxes are probaby slightly broken in Opera, also giving a look!)

I pushed out some fixes earlier today that I thought would address most of them, I'll check those out in particular!

I want to take a minute to explain what's actually going on with the site, because I think some of the context is getting lost.

For the last few years, the legacy Subeta codebase has been in a genuinely fragile state. I'm not exaggerating when I say that making almost any change risked taking down the site, sometimes for days. This is the main reason I built Kumos - not because I wanted to split the community or change what Subeta is, but because the foundation underneath the site we all love was quietly crumbling, and I needed a way to keep things running while I figured out how to fix it.

The good news, and it really is exciting news, is that after weeks of hard work, I've brought legacy Subeta up to PHP 8.4. That's a jump from PHP 7.2, which was end-of-life and was a significant part of why changes were so risky. I also rewrote the core layers that handle our database and caching. These aren't flashy, visible updates, but they're the kind of thing that means this site can keep running for another 20 years. That's the goal.

Now that the foundation is stable, I can actually make changes again. That's wonderful. What that also means is that I'm cleaning up years of accumulated frontend chaos — we're talking 5+ JavaScript libraries, hundreds of individually styled pages built across different eras with different frameworks, and (my personal favorite) over 500 places in the CSS where font-size is set. That last one is not a feature. That's years of band-aids. It needs to go.

While I do that cleanup, some pages are going to look a little off. Font sizes, spacing, layout... things may be temporarily weird. This is expected and normal, and it will get better. What would genuinely help me is knowing where you're seeing it. If something looks broken:

• Take a screenshot if you can (you can now drag and drop images directly into forum posts!)
• Note which page you're on
• Describe what looks wrong

That kind of specific feedback is what actually moves things forward. "This looks different from before" doesn't give me much to work with — a screenshot of the Forum Groups page with the font looking huge absolutely does.

I'm really glad to be here, still building this thing!