Following discussions with the community this post is to address various concerns and issues. To start I’d like to concretely clarify on some of the most concerning rumors.
WISP is not dying. Revenue is up month on month and has been since it was launched. New signups only continue to rise. There is no financial strain.
WISP is not abandoned.
WISP does not have any known security vulnerabilities.
I still love and care about WISP.
Support
Support and communication is a big pain point for our customers. This has left a good number of customers feeling ignored, and unacknowledged. This is a regrettable mistake.
There will be two new support agents in Discord within days, and I’m considering hiring a community manager just for Discord if I can find the right person.
Starting today we’re on-boarding new support agents who will be able to handle better triaging. This should be complete within days & the specific people will be announced in Discord as they’re cleared to actually perform tasks.
A lot of customers have previously had issues with emails going unanswered as a result of them emailing from an address that isn’t registered directly with WISP. We will be opening up the filters to allow these emails through, and informing customers more clearly that they need to email from the address the email used to sign into wisp. This is already done.
We moved from ticketing to emails, and this is something that many customers have expressed dislike about. Longer term we will be migrating to a ticketing system.
Development
Development has been frozen for a long time, only focusing on maintenance and security issues. Tonight the issue with logs.panel.gg has been resolved. Looking out a bit further these are the issues customers have highlighted that I will be focusing on immediately. For now I’ll be handling development as a lead. Long term the project needs at least one additional developer, and I’ve reached out to people to start this process.
Priority issues:
Modpack manager failing
Server transfer system
Notes
Finally I’d like to thank customers who have remained patient with me & WISP over the last year, since there has been a breakdown in communication.
By default this will prompt you for the required information. Alternatively, you can use the query strings license_key and instance_url to automatically insert that information skipping a manual prompt through CLI. For example:
By viewing the above page, you can see how the information is used in the script, and modify it to suit your needs. Please note the URL must be HTTP encoded, you can read more about that here. You also want to include the encoded https:// at the start of the URL. For example, testing.panel.gg would look like this when it’s encoded: https%3A%2F%2Ftesting.panel.gg
As a followup to the release of our latest major update, here’s an update on the translation progress. We will be expanding on the supported languages steadily, German and Turkish are currently close to being finished.
You can set the default language in the admin area. Users are able to set their own language on the account page by clicking their profile picture in the navbar.
We hope this will make WISP more accessible to international users. We hope to add more languages in the future, and we’re currently working on Spanish, German and Turkish and many more for the future.
If you speak a language which isn’t listed above, don’t dispair! You can translate the game panel to your own language yourself, through our Crowdin. We have a translators channel on our Discord, which you can use if you have any questions. There is more information on our notion.
Our next post will be when we release the new modpack manager as soon as I can share more
They said it wouldn’t be done. Some said it couldn’t be done. After a half-year of delays and false starts, we’re finally ready to upgrade all our customers and finally deliver on our promises.
We hope the update isn’t a major event for most of you, but WISP 2 is a major update for us. It’s an important stepping stone to make sure WISP doesn’t suffer long term from technical debt and to make the leap onto a more modern technology stack sooner than later. We can now focus back on our core goal and values – bringing unique and innovative features to your customers.
Top-line items for admins
Update is rolling out at the start of Febuary – 12th or 13th currently
New client & admin (formerly application) API
Custom CSS & JS may need updating – will be disabled
There will be some downtime – ETA 1-2 hours
Audit logs & notifications will be cleared
Impact to your operations
If you use the WHMCS module or application (admin) API to automate deployment, you will need to update your systems or module later this year, when the new admin API is being rolled out. For now, everything will continue working as normal, and no changes are needed.
The client API isn’t going to continue working, and any implementations will need to be updated to utilise the new API. The good news here is that the client API will now be much more exhaustive, meaning your clients can basically automate anything they can do through the panel. You can share the new client API documentation with your clients here.
If you have custom CSS or JS that changes the design it will likely need updating. The front end has been rebuilt using tailwind, so all the classes are different now. One advantage of the new frontend is that we hope to soon allow more extensive modifications to the front end, and we’ll be posting more information on that as soon as possible. For now, as soon as the update goes live we will disable any modifications to prevent things from getting ugly. However, you will be able to view and re-enable your modifications in the admin area easily. Any custom branding will continue to be used like normal and shouldn’t need updating.
There will be some downtime. Generally, we always try to avoid downtime on the game panel, so this is something that we understand might cause some frustrations and we will aim to minimise this as much as possible. From our internal testing, we expect it to last around 1-2 hours. The amount of time this actually takes may vary a bit. However, this is the only downtime we expect.
Notifications and audit logs will be purged as a one time action when we release the update since the new systems are more advanced and the old data isn’t directly compatible.
The admin area has been updated. The design is now inline with the rest of the product, and I’ll let the screenshot below speak for itself. Everything should be in roughly the same place, so you should have no issues adjusting to it.
There are some minor changes, one being the ability to re-send announcements. A slightly more major update to the admin area is that all admin API keys are now shown, instead of just yours.
Impact to your customers
There are a few changes that will be immediately apparent to your customers. However, none of these changes should impact their user experience negatively. There will be some changes to the site UX that you should be aware of.
One obvious big change is the navbar change from the top to the side. The new navbar design has the same page navigation structure and can be changed back to the top in the user account settings.
As you might have noticed, there is also now an option for users to set their language in their account settings. The default can be set in the admin area. More information on languages below.
The graphs are one of the most used features by customers. So we made sure the graphs feel as premium as the rest of the game panel.
We made them animated, obviously
Then we made them really fast. They’re so fast they will dynamically adjust the animation speed based on the latency from your server on the fly
They show data values on mouse hover, to allow faster interpretation
They have longer timespans. You can now switch between a 5 minute and 1 minute timeframe on the graphs
There will be lots of minor changes your customers might notice, and I’ll run through some of those quickly.
File searching is now built into the file managerAudit logs have a new look
Creating schedules is more verbose and uses cron syntaxEasier SFTP access for supported applications
Some other small changes they might notice:
The site now has skeletal loading
Subuser permissions now include literally everything
You can upload folders through the file manager (drag & drop)
Startup parameters save automatically as you edit them
Backups can be scheduled and locked to prevent accidental removal
Disk usage is now visible realtime
In conclusion
You will not need to make any immediate changes, and staff shouldn’t need any training to use the new admin area. The admin API and WHMCS module will continue to work as normal, and we will be providing an updated module when we release more documentation on the new admin API. There will be a deprecation period in the future for the old admin API before we eventually phase it out, but you will have ample time to update any integrations.
Your customers shouldn’t have any unexpected surprises or issues using the new site. The most major change that people might take some time to adjust to is the navigation being moved to the side – we hope the setting to switch back in the account settings will remedy any friction from customers who dislike the change.
Additional languages will start to be rolled out soon after the update, and if you want to help contribute towards a language keep an eye on our Discord.
What next?
Once we iron out all the teething issues with the new update (we’re sure there will be some) our focus will be on features and better customisation. Updates should be more frequent.
There shouldn’t be another update-blocking-update in the future like this. The final major hurdle will be the daemon rebuild, paving the way to allow more extensive modding and customisation – but this isn’t something we are going to start on for a while at least, and it shouldn’t result in updates to the panel being delayed while we work on that.
We should be releasing the front-end source code relatively soon, allowing you to take customisation to the next level – watch this space.
Almost all updates have been QOL/maintenance for the last 6-12 months, while we’ve been working on our first major update. I first spoke about it briefly on my last blog post, a year ago:
“Due to the large nature of the job ahead, it’s likely this will open up a window for competitors to try and catch up with us.”
To some people, it can look like we haven’t been doing much over the last 6-12 months, because there isn’t much to talk about. But in that time we’ve expanded our team with a new developer who has almost exclusively worked in the background on WISP 2. There has been significant progress, and we’re almost ready to release it. This will be a free automatic update for all our customers.
For the most part, people don’t care about updates under the hood, so we haven’t made much noise about this update. As long as everything pretty much works, most people are a lot more interested in features and updates they can see and use. But now WISP 2 is close to release, this is a blog post to try and show what we’ve been working on and some things your customers might notice when WISP 2 rolls out.
It’s all about the details
We should be clear from the start, this is an update focused on details, not features. WISP launched with some rough edges, and this update is for details that you hopefully overlook when normally using the panel in the future.
For example, all pages load faster, all forms now always provide consistent context-relevant errors, and the panel is now fully localized. Contrast has been improved to help those with impaired sight. Every delete button has a confirmation warning that requires text input to confirm. We’ve swapped vague terms like “data vault” and “server action logs” to more consistent and sensible terms like “backups” and “audit logs”.
Remote install with realistic load times
Pages and padding have been thoughtfully condensed by hand to make better use of the screen space without cluttering. For example, the file manager no longer contains tools on the sidebar. They have been moved to the top and put in the context menu. We plan to add a directory tree-view alike Windows Explorer there in a future update.
UI improvements
The popular original Ptero-style sidebar has made a return. There was a reason it was popular; it’s intuitive. We’ve added some useful information like usage stats, and disk usage. The top navbar that WISP launched with is also still available – set your default layout in the admin area.
All information on the UI is shown real-time
The combined graphs on the server console page made things confusing, and hard to read. We replaced it with two separate graphs. There’s also now a tool-tip when you hover over graphs so they’re easy to read.
Original WISP graphs
New WISP graphs
We spent probably too much time working on making the graphs near real-time and easier to use. Now you can switch between time intervals to show usage over a period of between 1-5 minutes.
UX improvements
Our Minecraft version manager has been redesigned to be more reliable, with various new editions being added. We’re leveraging the WISP infrastructure to provide a much faster and more reliable experience, by serving cached and prebuilt resources privately.
This makes our service reliable in the case of an outage at Paper, Forge or Spigot etc. Additionally, in the case of Forge, it cuts install times down from ~5+ minutes to under 10 seconds.
Due to the popularity of this feature, and recent MC updates, we’re pre-releasing this feature within the next few weeks to all our users. Combining it with a game server using the image we shared the Java version will be automatically be selected on boot. Your customers don’t even need to think about it anymore. They just install what they want & start the server. There’s an option to override the automatic version on boot if needed. You can update the image URL to our one on any existing game server or egg without losing any data.
Following WISP 2, we plan to do a similarly major upgrade to the Minecraft mod pack manager. Details about this aren’t concrete, but we have some interesting ideas that we don’t want to share too much about this early. If things work out, our modpack manager would probably be ahead of companies that directly integrate/sponsor the modpack/launchers with a feature to automatically build a server for modpacks that only provide a client edition. I’m getting ahead of myself here though. We have some other things planned after WISP 2 that I can’t wait for us to start showing you.
Improved tooling
We’ve re-tooled a bunch of “invisible” things too. Like the entire user permission system, to pave way for advanced role-based access in the future. This will allow you to compartmentalize staff permissions for better operational security.
Wrapping things up
Like any product launch, we learnt a lot from the initial iteration of WISP and used those lessons to shape how we designed WISP 2. For the foreseeable future, we will be focusing on features updates. WISP 2 has taken a while, and I wanted to thank everyone who stuck with us while there was some unwarranted uncertainty and doubt about if we would ever release it. The team worked really hard on this update, we’re aiming to release it before October.
We haven’t posted here in a while, but it is time to wipe the dust off the ol’ blog. As I’m sure some of you have noticed, our second headline feature had just rolled out – marking the game panel as ready for production release from a feature standpoint.
The two features I’m talking about are our modpack manager & plugin manager (not to be confused with our mod manager). The key thing about these systems is they’re fully automated, meaning companies don’t need to manually maintain a large amount of mods. These systems are also inherently much faster than installing modpacks or plugins manually, saving your clients time too.
As far as we’re aware, WISP is the only publicly available game panel to offer these features – firmly asserting our goals to remain laser focused on keeping our customers on the bleeding edge of innovation.
Launching Soon
WISP will be production ready and publicly available before the end of July, and this means a few changes are to be expected. We will be rolling out our final design update, to tighten up some final bolts & align our branding. There will be a follow up post regarding that.
When WISP is released for sale, all the users on our beta will be given 30 days to activate their subscription. Once they activate their subscription with a valid payment method, it will renew every month.
Future Bound
From now on future features will be disclosed to hosting companies before we push them out. This will give companies time to prepare their own marketing materials, making their customers aware of upcoming features – so these things don’t just come as a surprise to the company and the customers.
We’ve been internally talking about what we should be aiming for in the future, and one thing we keep coming back to is customization. We’re making plans to allow modding of WISP, and a full theming system. This stuff would require a relatively major rework of our code base, requiring us to turn WISP into a SPA. While this wouldn’t inherently provide any new features, it would provide three key benefits – mods, themes and pretty major speed improvements.
This is a situation where we need to take two steps backwards in order to take one step forward. Due to the large nature of the job ahead, it’s likely this will open up a window for competitors to try and catch up with us, and our customers. But we think this is a sacrifice worth making in order to give our customers a greater level of control over their game panel in the long-run.
Long time no post! When we announced that we were going to overshoot our October goal we promised some technical posts, and here’s the first one.
WISP includes automatic updates. That can be pretty scary, so naturally there are questions about our processes — what if we push a bad update?! First let’s start with the update channels.
Update channels
There will be three update channels you can select between. Our public update channels are as follows:
Staging – this is our experimental branch, expect bugs to crawl in
Beta – we think it’s ready for production but we’re still testing
Production – this is the stable channel we assume most people will use
While we’ll still have our own internal testing, we’ll be utilising these channels to better test features & identify issues.
You’ll even be able to select different channels for different components. This means if you want to run your SFTP-server on the beta channel, but you want your daemon running on the production channel – you can!
What if it goes wrong?!
This is a common question we get. Because the updates are automatic, what if they go wrong? WISP’s bootstrapper will jump through the hoops you would normally jump through if a manual update goes wrong. Let’s follow along a WISP startup log:
[BOOTSTRAPPER] [INFO] Hello world!
[BOOTSTRAPPER] [DEBUG] Registering projects...
[BOOTSTRAPPER] [INFO] Project daemon is missing, forcing it to update...
[BOOTSTRAPPER] [DEBUG] Running VersionChecker...
[BOOTSTRAPPER] [DEBUG] Polling...
[BOOTSTRAPPER] [DEBUG] bootstrapper - current: v1.0.0, latest: v1.0.0
[BOOTSTRAPPER] [DEBUG] daemon - current: v0.0.0, latest: v1.0.0
[BOOTSTRAPPER] [INFO] Update available for daemon! (current: v0.0.0, latest: v1.0.0; channel: production)
[BOOTSTRAPPER] [INFO] Delaying startup until everything is updated...
[BOOTSTRAPPER] [INFO] Updating daemon to version v1.0.0...
[BOOTSTRAPPER] [DEBUG] Downloading new version of daemon... [daemon.wisp, package.json, package-lock.json]
[BOOTSTRAPPER] [DEBUG] Downloading the file daemon.wisp...
[BOOTSTRAPPER] [DEBUG] Verifying signature...
[BOOTSTRAPPER] [INFO] File daemon.wisp is intact and signed by Stepan Fedotov <[email protected]>.
[BOOTSTRAPPER] [DEBUG] Downloading the file package.json...
[BOOTSTRAPPER] [DEBUG] Downloading the file package-lock.json...
[BOOTSTRAPPER] [DEBUG] Installing dependencies...
[BOOTSTRAPPER] [DEBUG] Executing npm install...
[BOOTSTRAPPER] [INFO] Update finished for daemon, new version is v1.0.0. Proceeding to run the process...
So far everything looks normal. Here comes the simulated failure:
[BOOTSTRAPPER] [WARN] Failed starting process for daemon: Error: Process exited with code 127
[BOOTSTRAPPER] [INFO] Starting the updated version failed, rollbacking to previous version...
WISP will automatically rollback when it detects a failed update. But what if even the rollback goes wrong?! What would you do in this situation? Maybe try a fresh reinstall?
[BOOTSTRAPPER] [WARN] ROLLBACKED VERSION FAILED - DELETING PROJECT IN HOPE OF REINSTALL FIXING THE ISSUE.
In the case the rollback also fails, WISP will reinstall itself for you; leaving the game servers intact of course. It will also skip the version which caused the failure in the first place, downloading the last version that was running successfully on the machine.
Okay so what about MITM?!
The eagle eyed amongst you would have noticed in the startup log earlier that we’re using signature verification on each update, to verify it was signed & distributed by our team, here it is again:
[BOOTSTRAPPER] [DEBUG] Downloading the file daemon.wisp...
[BOOTSTRAPPER] [DEBUG] Verifying signature...
[BOOTSTRAPPER] [INFO] File daemon.wisp is intact and signed by Stepan Fedotov <[email protected]>.
Using signature verification we can protect from MITM attacks on peoples networks.
Okay, well what if your update server gets hacked?!
We have taken every step possible, including physical access keys, to lock everything down like a bank. But we aren’t going to make someones job easier by sharing anymore than that. However, if you look into our teams track record you’ll know we’re very security conscious and almost every design decision is made with security in mind.
Running with the idea that something does happen, though – virtually everything is containerised; minimising the impact on your host machine. We will also have procedures pre-planned for a breach event, and it wouldn’t go unnoticed.
Currently (literally) physical attacks are outside of our threat model, so we feel pretty confident knowing that’s how far things would need to get. But in case someone is worried about that too, none of our public company locations have access anyway.
Footnote
A lot of hosting companies particularly pay for their bandwidth usage. So they’ll be happy to hear our daemon is less than 1mb.
It’s time to say goodbye to manual updates, but that’s all for today folks! More sauce coming soon?
There has been quite a few misconceptions and myths about WISP, how it will be hosted, and our on premise solution. This should clear up why the cloud offers advantages, and our on premise panel.
Why is WISP hosted in the cloud?
We host the game panel, and you install the daemon on your nodes. This communicates with the game panel and allows you to easily manage game servers on a number of nodes with no work required.
Because we’re hosting the game panel, it’s important it doesn’t go down, so we have servers distributed globally that can dynamically handle incoming traffic. Traffic would be routed around any failure within seconds.
Traditionally, you would need to setup the mail server, web server, database, ssl, and more yourself. We take all of this out of the loop and enable you to deploy a game panel with a single command.
This is only possible because WISP is hosted in the cloud; which enables us to monitor performance, perform maintenance, responding to any issues much faster.
Additionally, things like DDoS and scaling up and down are managed discreetly and quickly, for you. This allows you to focus on your customers, and expansion.
What if I want to use my own servers?
Under reasonable circumstances we can do on premise hosting of WISP. However, this doesn’t come without risks. Due to the increased time associated with managing an on premise environment, we may only do it if we deem it truly in the customers interest.
If you’re planning to use less than 3 POP’s in the continents we cover, you would only be exposing yourself to increased risk of downtime.
Example use cases for on premise
If your game nodes are having latency issues with our game panel, we may provide on premise solutions, however we would generally want to have at least 3 POP’s to ensure QOS.
If you’re operating in a country which requires all data to be kept within said country, this might make geo-distribution redundant and we can run on-premise with less than 3 POP’s.
For large companies that provide complex network topology, SLA’s, liability contracts, or complex data management/transfer contracts, we can provide on premise, however this will need to be a WISP unlimited license, which starts at $2000/mo for unlimited nodes.
To ensure a high quality of service, we will review each request for on premise individually.
Hey guys it’s been a while since we posted here. We’ve been working as hard as we can to get the beta ready for October, and we’re excited to share it with you all.
Design Progress
We’ve made a lot of design progress on the game panel, and I’ll be sharing some screenshots below. If you’re in our Discord – you’ve probably already seen these
First draft of the security pageDraft of the SFTP details panel, highlighting the password info boxFirst draft of the Server Action Log
Migration System
Aside from the design work, we’ve been making a lot of progress on our migration system. It’s going to be broken out into four steps
First, the system will prepare your WISP panel for all the game servers, nodes, eggs, etc, on your existing Pterodactyl. We get this information from Pterodactyls API.
If you preform an automatic migration, you will be able to email all your users to setup their new account passwords, and they will be told that their services have been moved to a new game panel.
We can preform manual migrations, which wouldn’t require password resets, and can migrate more data, more accurately. Contact us for more info
We pair this information with our daemon install process, to automatically detect and migrate servers from Pterodactyl on a node-by-node basis when you install WISP. You will be asked if you want to move the game servers to WISP, or if you want to install WISP alongside Pterodactyl.
Infrastructure Planning
Generally change is what causes downtime, so we want to avoid radical changes during production for WISP. We need to plan out how we’re going to provide the service and up-time we’re promising.
We’ve been planning some upgrades in preparation for WISP, to increase our web infrastructures throughput. Our infrastructure is already capable of handling ~35,000 unique users a month. After the planned upgrades we expect that capacity to increase by 5x.
We have an extra focus on the USA, because that’s where we expect most traffic to be coming from. So we’re gearing up our USA POP with over double the compute power as our EU & Oceania POP’s.
Traffic will be dynamically load balanced and routed to the fastest POP for any user, and outages will be automatically routed around almost instantly.
Obviously we can upgrade specific continents as needed later down the line – but we feel this start will provide more horsepower than we will need for a while, and should ensure long term stability of the service through rapid growth.
October Beta
Next month we’re going into our beta period. We’ve got a team of beta testers selected, and we’re going to work with them to integrate the service into their company.
During this period we’re going to closely monitor the service, and ensure any snags are dealt with before opening up orders to everyone. Depending how this goes, we’re aiming to launch in October, or shortly after.
Summary
There have been some setbacks but things are looking up, and we’re making great progress. This project and it’s deadlines have been ambitious, but the finish line is now in sight. The only thing that’s probably slightly behind schedule is the billing panel, more on that in the next post!
I thought it might be interesting to some people if we shared the inside development of the WISP brand, to show you where it all came from.
Logo
Our logo was designed by Vested – he loves design. He’s really creative & good at drawing, however this was more of a GFX logo and I didn’t give him much information on what I wanted – it just needed to be “cool”. I’m a bad person I know.
I figured we would at least be able to get some creative ideas down for place-holder images on the site.
Original WISP logo designs
A few days in, these are the first concept logos we had. We knew it wasn’t done, but it was something to work on. I sent back my initial revision idea (Bottom)
Bottom: concept revision
The notable changes are the I, S & the (incredible) P. After making adjustments for those, Vested still felt something wasn’t working. So at this point things got a bit experimental…
Yikes, glad we didn’t choose thatThis was a thing too
But it wasn’t too long before we finalised on what we still use as the shape for the logo now
The current WISP logo with bright colors
While we weren’t happy with the logo it was good enough to start working into a concept site. From there I thought we would know what to change on the logo.
Website
At this point I forwarded the logo designs to our site designer, Havasu – who is really taking the design lead on WISP currently. He was given a “mood board” of sorts, so he had a general idea for the feel we wanted on the site.
Concept mock for more ideas
This was a mock concept, to just try and get some colors and ideas flowing. We wanted to highlight the easy installation, and custom features. There is a video – which is still planned for the current site. We ended up replacing that temporarily with a design of the Pterodactyl panel.
For the eagle-eyed out there, you would have noticed the “Versus TCAdmin” & “Versus XenoPanel”. We’re planning to release these pages soon (XenoPanel was replaced with MultiCraft) so watch this space!
Original site concept
The next day Havasu cleaned up the design, and this was the first real look at what was going to become our brand identity. The color choice was perfect, and so different to what I was suggesting previously, but this is why I give people like him the time & space they need to do their thing.
Revising the logo
Havasu suggested we make the logo white, so Vested started experimenting with that, and we really liked it.
White WISP logo concept
After a little more tweaking, we pulled the gray & added the green highlight to end up with our current logo. We used the color scheming for our smaller, square logo – so it’s not just a white W
We popped the new finished logo on the site, and it was starting to come together…
From there we worked to build out the website we have now. Our website is primarily there to raise awareness right now. We hope to put out more useful information on some upcoming updates.
Final notes
Thanks to Havasu & Vested for defining the brand, and being flexible with as much change as we had going on. I’m happy to work with people who love what they do, and it’s what will make WISP great.
We will continue to tweak and tighten up the brand identity, but there wont be any radical changes. We’re aiming to expand the design language from our front end site onto the game panel, etc.
That’s all for today folks. I’ve been showing a lot of design by Havasu & Vested, but not much by me, so as a reward for finishing this post, have some Drizzy art:
