[R5N3T]

It's really DNS that's the problem for users. We will almost certainly have 1-2 hours of downtime just for the server move. What I'll do is time how fast I can download HF's DB into a dump, move it, and insert into the new server. Because technically that's the minimum amount of downtime we'll experience. From past experience that should be just a couple hours. I can also try to time it on a slow day like Sunday.

I'm almost done for the day. I have a couple things to do and will resume in the morning but for a first day, very pleased with progress. The server coming along nicely.

I should be able to moves files tomorrow. That's when the real work begins which is debugging HF's backend for the PHP upgrade. 1500 PHP files have to be reviewed and updated to work with PHP 8.3 vs the 7.2 we run now. This is the first hard part, then the socket is the second, and lastly the most difficult will be Convo. But after that, we're going to be awesome.

Alright, great Omni. I trust you to do your best. Thank you for ur service 🥰😍

[Omniscient]

Day two. I'm going to get some morning work done (usual stuff) and then back into the grind. I should have even better work flow today. I expect to be moving the files and database.

[5chn4pp]

Considering you have already made it this far with running the site, I wouldn't doubt your abilities, good luck to you and Hackforums itself.

[SwimmingPool]

good luck

[Null State]

I seem to remember the same apprehensiveness the last time this was done also, and it all turned out fine albeit now there's a lot more to features wise that wasn't there back then. Good luck Omni!

[Hackers]

Good luck, and I am more than happy that AI will make the process easy this time.

Hackers I know you pray the convo never comes back lol.

Only if it is a net positive. My suggestion is based on Omni's previous comments that convo is killing the forum. If that's not true and it is saving the forum, I would vote to keep convo.

I like convo. I am willing to lose something I like if it is beneficial to HF as a whole, over the next 5-10 years.

[7]

if convo is lost we will rebuild better I promise!

[CL1B]

Convo not getting lost because of server migration. Stop scaring the kids.

I don't know why people including Omni keep thinking that this is likely.. A socket server chat has to be one of the simplest things in the backend, even if it was implemented in a weird way. It's very unlikely.

Tip for Omni: Dockerize it and run Cloudflared on path /convo.php

or Nginx but for such a simple service I wouldn't even bother.

As far as Notify and Convo running in 1 js file, that's fine too.. In context of HF's usage and average concurrent connections; Perfectly fine, it's simply about broadcasting nothing else.. Many huge platforms with millions of daily connections do a similar thing and hide it behind a gateway for UX (Simplified of course).

For example gateway.hackforums.net

We're not using PubSub, Redis or other shared state managing either so I think we're good here.

No?

[Omniscient]

Convo not getting lost because of server migration. Stop scaring the kids.

I don't know why people including Omni keep thinking that this is likely.. A socket server chat has to be one of the simplest things in the backend, even if it was implemented in a weird way. It's very unlikely.

Tip for Omni: Dockerize it and run Cloudflared on path /convo.php

or Nginx but for such a simple service I wouldn't even bother.

As far as Notify and Convo running in 1 js file, that's fine too.. In context of HF's usage and average concurrent connections; Perfectly fine, it's simply about broadcasting nothing else.. Many huge platforms with millions of daily connections do a similar thing and hide it behind a gateway for UX (Simplified of course).

For example gateway.hackforums.net

We're not using PubSub, Redis or other shared state managing either so I think we're good here.

No?

While I wouldn't say that Convo code is complex. It's definitely not a simple socket. Remember, it's partially PHP, integrated into the forums, and has actually a lot of nifty features written into it.

I don't want to add complexity like Docker (hate containers). And Cloudflared isn't needed either, I have real issue using 3rd party services I can't replace. If I build HF around CF services and they boot me, then what? No, HF needs to be as self-contained as possible. We are always at-risk. Today CF has a very neutral stance but as a publicly traded company what happens if the Board recommends a policy change and I'm booted, then what? I'm always prepared with a backup plan to keep HF online. From Registrar to Hosting, I have HF under my control only. This is why we don't have integrations like Discord or any service I can't replace within a few hours. And while CF is an excellent service, at the level I use it, there are alternatives.

btw since GPT has helped me on Convo frequently, I asked it about the complexity.

AI Quote:
I’ve only seen pieces of your Convo NodeJS setup in this chat (the old Node 12.21 context, that it does chat + notifications over websockets, and the “heapdump is in deps but not referenced” situation). I have not seen the full codebase end-to-end here, so I can’t score it like a full code review.

That said, based on what Convo is (real-time chat + notification socket service) and the Node 12 era patterns, I’d describe its complexity like this:

### Complexity level: Moderate code complexity, High operational complexity

Why “moderate” code complexity
Real-time websocket apps tend to be event-driven, which keeps individual functions small, but spreads logic across many handlers (`on("connection")`, `on("message")`, presence, joins/leaves, typing, etc.).
Most “complexity” usually comes from:

state management (who’s online, rooms, permissions, rate limits)
message routing (broadcast vs room vs user)
auth coupling (session/cookies/token verification with PHP/MyBB)
edge cases (reconnects, duplicates, partial sends, backpressure)

If those pieces are handled in a straightforward way, the code feels “medium”.

Why “high” operational complexity
Running it reliably is harder than the code looks:

long-lived connections (memory leaks matter)
load balancers / sticky sessions (if you scale horizontally)
reconnection storms
logging/monitoring (why heapdump was probably added)
dependency fragility on an old runtime (Node 12 + older libs)

### In plain terms
If it’s a single Node process with socket handlers + some DB calls: medium complexity
If it includes rooms, permissions, anti-spam, Bytes features, notifications integration, and shared auth with MyBB: upper-medium complexity If it’s multi-process/clustered, has Redis/pubsub, queueing, or cross-server broadcasting: high complexity

### A quick “tell” for where yours likely sits

The fact that heapdump exists as a dependency but isn’t referenced strongly suggests:

a prior dev was chasing memory growth or leak suspicion, or
* they used it temporarily during load testing.

That leans toward: the system had real operational pressure, even if the code isn’t “fancy”.

[CL1B]

Omniscient Yeah OK, valid point with the CF dependency risk.

[Omniscient]

Omniscient Yeah OK, valid point with the CF dependency risk.

Also note..."Convo not getting lost because of server migration. Stop scaring the kids."

Yeah but when I "save Convo", I'm a hero. :)

[CL1B]

Well said ;) haha, good luck man.

[Target™]

Awesome this sounds like a great plan!

[Envy]

Will HF lose threads/posts/activity/changes or will you have a way to sync databases?

If you read the thread he already answered your question with "Move HF to new server", "Use hosts file", "Change DNS". Surely not his first rodeo.

Forum would go into maintenance/offline mode for the duration of the transfer and/or replication can be used, both of which are standard MySQL features.

If he decides to leave it online, tinkering in production while simultaneously staging on another server it'd be his own mistake (not that he cares about a few lost posts here and there).

Pretty normal migration, nothing unusual but still anxious work.

[Omniscient]

Actually AI helped me figure out something even cooler for Dev.

Instead of changing my Windows Hosts file, which changes things on the whole desktop, I can start Brave (Chromium) with a flag.


"C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe" --user-data-dir="C:\BraveHFTest" --host-resolver-rules="MAP hackforums.net 8.8.8.8, MAP www.hackforums.net 8.8.8.8"

I then get a Brave warning about the cert but apparently if you type "thisisunsafe" you override the security rule. Very F'n nifty.

So now I'll basically have both real HF open and Dev HF at the same time.

Thought that was cool enough to share.

Today I didn't get as much done. Mostly worked on tuning MySQL and PHP. AI gave me some trouble with the help because I'm experienced enough to see that what it wanted to do was a bad idea. I asked for tuning configs and it went way overboard on what I needed. Annoyingly it didn't even ask for my existing confs to compare. I use a Control Panel and it didn't seem to take that into account on the tuning either. Basically assumed default Debian package installs, which this really isn't. It's close, but not exactly.

I didn't get the best sleep last night. It's Saturday and Valentine's Day. Wife is away, I think I'm going to call it a few hours early and get some mental rest. I'll resume the big work tomorrow but unfortunately I will also be babysitting the granddaughter.

Thank you.