What is required to run a Tiki? First of all, a person.

Congratulations and thanks for your interest in Tiki Wiki CMS Groupware. We hope Tiki will meet your needs for a highly configurable web platform. If there is anything we can do to help, be sure to let us know.

The requirements page is quite explicit about what you need in order to run a Tiki instance https://doc.tiki.org/Requirements?highlight=requirements . So we hope that any system administrator will be able to find a proper environment to run Tiki. It really isn't much to it, at its core Tiki is (very) simply put a PHP website, so it will happily run where your other web applications run. But if you are a beginner in this field of system administration, you should:

• take the time to learn a bit about the different web hosting technologies;
• try to mimic certain recipes available online, though you should in time always make your own decisions and come with your personal way of providing a Tiki to users;
• have patience but also have a bit of courage, this means it is an advantage having the inner desire to perfect your skills, but with an eye on the future, always eager to try new things. Passion helps here, a lot;
• be ready to become a tougher individual, ready to deal with the 24/7 stress of running any service others depend upon, more so with all the bad stuff happening online. This is no joke, you should expect problems, in fact problems will become your very job: either from your software/hardware stack, by your own hand or your users, and also via the armies of crackers (not hackers, please learn the difference) just waiting for you to have something, anything online. Down to your electricity and internet providers, whom will become your archenemies if building your own infrastructure;
• get in shape to build trust around you. A sysadmin that doesn't have a good moral compass is a danger to himself and others. Knowledgeable admins can be easily found. Trustworthy ones, at a level that people will hand over to you their personal info, sensible files, their family's well being and even the future of their company - that kind of person is more rare.

Let's go through your technical options now and also a few other points you might want to consider.

Shared hosting and cloud VPS

So where to host? The popular option is to either use a shared environment as the go to "pay and play" or rent a VPS, from a provider.

• In the first case you will not have to deal with the intricacies of having to set up a whole server, and everything is ready to go for you for the smallest price compared to the other options. Usually, just don't pick the cheapest offer out there, because it will have hidden costs in the terms of functionality, resources and availability. Simply research your provider, get the most for your money, and just try it out as there is not much administration involved. And it is standard to be able to scale your resources.
• Only in the second case, you will elevate yourself to a true sysadmin as it will be required of you to set up a server for your services in a virtual machine provided by a third party. This is a good option if you or your organization, don't have the resources, you aren't interested in running you own servers, or you just need to test your hand. Keep in mind this option is feasible only in the basic to mid tiers - prices will climb up quickly if you need more resources. This is the point where you should calculate how much will it cost you in the long run.

Roll your own. Containerized, virtualized or bare metal?

If your organization already owns the infrastructure or they intend to build one, you are not alone. In the cloud era, there is also a resurgence of the need to own your stuff, for privacy reasons mainly but also costs, if you have needs exceeding what is offered by subscriptions for some cloud VPS instances or even renting physical servers. A few points here.

• Members of our team are making good use of container technologies like docker and podman, but mainly for developing and testing; it is not something we see often in production. It can be used just fine but in our experience the organizations are using containers for Tikis less often than the next two scenarios.
• Virtualization is the the go to option for setting an internal but also a public facing Tiki. Popular virtualization technologies like KVM and Xen, or commercial solutions like VMware have no problem with a common web server + php and some SQL databases in a VM. And of course they are ubiquitous in modern corporate IT landscapes, so it makes sense to use your existing infrastructure. We urge admins to build their solutions using virtualization if they didn't already, for security via segregation, ease of restoration and consolidation purposes to say the least.
• Running on physical hardware is required when no virtualization is in place because you might have older servers that do not worth the effort or they do not have the proper CPU instructions sets. Or when you plan for a monster of a Tiki that really needs all the resources and the lowest latencies possible. This is a return to the old mantra, and you know what to do if you aim that big.

GNU/Linux is the best OS for Tiki

It doesn't matter the distribution as long as you have a Tux under the hood, and there is no point in even mentioning the two major commercial operating systems that have a bigger share. Tiki shares the same freedoms and philosophy with this family of operating systems, being in fact one the many technologies they spawned. We don't see any problems if you want to host your services on a rolling distro like Arch or Tumbleweed, bleeding edge ones like Fedora or the distros for purists, like Trisquel.

Though in production the general consensus is that you should opt for "stability" as in a slower paced, maybe sporting LTS versions, with mature packages like Debian, derivatives like Ubuntu, RHEL rebuilds like Rocky Linux or AlmaLinux. You can't go wrong with any distribution when running Tiki, so it is up to you which one you choose, depending on other considerations and even personal views.

Here you can find comprehensive information about installing a Tiki instance in different environments https://doc.tiki.org/Tiki-Installation-Guide

First things first

As soon as you get you instance installed and running, you should check the following:

Backups

Yes, please start with backups. Weird thing to say to a system administrator, but everyone needs a reminder that losing data is not acceptable, at least not all the data. As soon as you manage to have a Tiki running or anything for that matter on a new server, you should start with making some backup decisions and put some automation in place from day one. Sooner or later this will spare you a lot of grief and it is only a matter of time before something happens, so it is not a question of "if" but a question of "when". Here is some info about what you need to do at a minimum https://doc.tiki.org/Backup which means having a database dump and your files copied somewhere else.

Permissions

Permissions issues are not common encounters in a shared environment as you don't manage much, your host does, and so it is their job to keep them in good order. But they do happen when you are charge. Their effects can be quite noticeable in any deployment starting from weird Tiki behavior, explicit errors in control panels and ending with complete crashes, but usually when you get them right, there is nothing more to it.

So problems rise due to user errors, a misbehaving script or inappropriate defaults in the OS/specific software servers. Never use full 777 permissions for anything and never run anything web as root, not even when testing as you will learn the very wrong lesson that they are a quick fix. Use 755 for folders, 644 for files, owned by the proper web user.

Resources

For sysadmins it is a good idea to over provision and also to have an alternative, a more scalable environment.

Availability and uptime

Monitor as much as you can

Check the health of your Tiki

Caches and indexes

Use a control panel if possible

Tiki Manager and the WikiSuite project

Secure everything to the point of false positives.

Where to get help

Tiki is a bit complex, with many features and preference options, and some things may be done differently than in other similar software, so familiarization may take some time. Please visit the documentation site for details on feature use, etc. Also make use of the sources of help listed on Get Help, in particular:

• Ask questions in the forums or in the Matrix chat.
• Get involved in the Tiki community.
• Please feel free to participate in our monthly roundtable meetings.