An octree is simply a spacial partitioning datastructure. It doesn’t matter whenever it’s clientside or serverside. It’s only important that it’s implemented on whatever side has the authority so that it can actually be used properly.
The use case here is that by grouping entities in separate nodes, it’s more efficient to search for a target because you’re no longer searching and comparing with every entity on the map, but only the entities inside the nodes that are in range.
As for implementation, I’d suggest you go search it up and try to learn for yourself - it will be much more useful if you can understand what is going on.
Keep in mind that I haven’t tested it myself. Though it’s important to understand how octrees work and adapt them to your specific use-case.
Octrees, though best suited for static objects, are still really good for dynamic objects - in fact, Roblox uses one for their physics engine. Ideally, insertion and removal are O(logN), which is good enough since you’re not adding new entities every frame the entire game. The main performance boost is the fast searching (compared to a brute force method).
Octrees can seem daunting. That’s ok. Challenging yourself and persevering is the way to success!
A quadtree might be better for your situation if the height level of the enemies and towers don’t matter to gameplay, like if your towers will hit enemies no matter the distance is height-wise. And it might have better performance than an octree aswell. But if you plan on including height/length as a part of the towers hit range then it’s a better idea to stick with the octree.