Vultr Docs is a knowledge base for the Vultr community, and we appreciate your submissions! To ensure the highest-quality information, we have a thorough review process. Please review this document carefully. You will find a glossary of our standard terminology, tips for writing effective documentation, and more information about the program rules.
We perform an initial screening of article submissions to Vultr Docs to check spelling, formatting, grammar, plagiarism, and topic suitability. If the article requires extensive editing, is plagiarized, or is not a topic suitable for Vultr Docs, we will notify you at this stage.
The Vultr Docs team performs a full technical review of articles that pass the initial screening. We test all the steps exactly as written. The article must pass this test without errors to be accepted. We receive many submissions, and the technical review is time-consuming. Depending on the number of pending submissions, the process may take several days to a few weeks. Please allow sufficient time for our team to complete the full process.
- You must submit only original content that does not appear on other sites.
- Do not republish the article on other websites, communities, or knowledge archives, before or after submission to Vultr, with or without modification.
- After payment, the content becomes the property of Vultr.
- Do not mention other providers that offer similar services to Vultr.
- You understand that we may edit your article to improve readability.
- Extraneous information padding article length will be deleted and may disqualify the article for publication.
- Violations of any program rules may lead to suspension from the Docs program and disqualify future submissions.
- Articles are submitted in the English language with proper spelling and grammar.
- Use a minimum number of URL links to resources outside of Vultr Docs.
- In most cases, we do not publish two articles on the same topic.
- Ports of existing topics to a different OS/platform must be written in this format.
- Ports of existing topics to a different OS/platform cannot have identical commands as the base article or another port. In this case, adding more substance to the document, such as commands further explaining how to use the software, would be acceptable.
- LAMP stacks or LEMP stacks for any platform will typically be reviewed as ports.
Banned topic list
- How to bypass or "crack" licensing systems of applications.
- Peer-to-peer sharing guides for programs such as Bit Torrent, etc.
- Anonymous surfing guides for programs such as Tor, Shadowsocks, or other proxy software.
- Game guides focusing on SteamCMD installation. Game guides should have a basic synopsis of how to install the game but contain information about using and customizing the game server. Link to this article as a reference to describe SteamCMD installation.
- Blockchain and cryptocurrencies
- Guides that require virtualization technologies (VirtualBox, VMWare, KVM, XEN, etc.) Vultr does not support nested virtualization.
Payments and rates
- New, original topics of 1500+ words (excluding code) are eligible for up to $300.
- New, original topics of 750+ words (excluding code) are eligible for up to $150.
- New, original topics of less than 750 words (excluding code) are eligible for up to $75.
- Ports of existing topics to a different OS/platform are eligible for up to $75.
- Payment rate will be reduced on articles that require minor corrections.
- Articles that need extensive editing will not be accepted.
- Your account will be reviewed for payment eligibility.
- For PayPal payouts, your PayPal account must allow you to receive payments. We do not process PayPal requests (to Vultr) or donation pages.
Users reading your articles are primarily interested in server administration and applications.
- Test your instructions on a new virtual server. The Vultr Docs team will provision a new server and test your article, exactly as written, step-by-step.
- When writing a guide for an operating system, target a specific version such as Ubuntu 18.04. Targeting an OS family, like Ubuntu, causes frustration when commands go stale over time.
- Use example domains and IP addresses. You'll find a list of approved IP blocks and domain names below.
- Use Vultr Flavored Markdown. See the Article Tutorial for text formatting examples.
- See our Vultr Doc Templates for formatting examples.
- When describing common tasks such as "How to add a sudo user", link to an article from our reference articles category.
- Please test all hyperlinks. We cannot publish articles with broken hyperlinks.
- It's usually better to explain how to locate the latest version of a software package than to link to a specific version. Avoid links to a particular version unless you have a good reason for insisting on that version.
- Use standard terminology. See our Vultr Glossary of Terms for common language examples.
Example Domains and IP Addresses
When an example IP address or domain name is needed in your article, please use one from this list.
Preview your Article Before Submission
Before submitting your article, use the Preview Article tab on the submission page. The Article Tutorial and Tutorial Preview tabs are also useful examples of Vultr-Flavored Markdown.
Use Active Voice
Active voice instructions are usually shorter and easier to understand.
- Active voice: Compile the script.
- Passive voice: The script needs to be compiled.
Shorter is Better
Documentation is not a blog post. Short sentences and fragments are better suited for documentation than long narratives. Edit ruthlessly, cut anything that isn't required.
For example, replace this:
The first of the tables that we will create will be the
/etc/credentials file. As the name suggests, this will be holding the username and password of each virtual mail account. If you notice from the smtpd configuration file, this is of type
passwd. We do this so that OpenSMTPD and Dovecot can share an authentication database and save administration headaches further on down the line.
OpenSMTPD and Dovecot share the
passwd format authentication database
Suggest Good Defaults
When faced with a choice, give the reader enough information to make a confident decision, but don't overload them with options. It's not required to explain every possible setting. Give the reader sane defaults for a basic configuration.
Use an Implied Subject
It's common to omit "you" and "you will" in instructional steps. It's implied that the reader is "you".
- Replace this: You will compile the script.
- With this: Compile the script.
Use the Oxford (or Serial) Comma
Documentation must be unambiguous. Use the Oxford Comma to avoid confusion. Compare the following examples:
I love my parents, Batman and Wonder Woman.
Unclear: Their parents are superheroes?
I love my parents, Batman, and Wonder Woman.
The meaning is clear: They love their parents, and love Batman, and also love Wonder Woman.
You have the advantage of knowing how your tutorial works. The reader is inexperienced. Consistent use of the Oxford Comma avoids confusion.
Avoid First-Person Narratives
Scan your documentation for the words "I" and "we". Vultr's documentation is a collection of articles written by many authors. There are no individual credits. Likewise, "we" could refer to the author and the reader working together, or it could refer to Vultr. Unless the context of "we" is clear, you should avoid these pronouns.
- Replace this: I recommend the free "Let's Encrypt" SSL certificate for Apache.
- With this: Use the free "Let's Encrypt" SSL certificate for Apache.
Use Strong, Clear, Action Statements
Avoid weak writing. Most statements should start with a verb. Avoid "you can", "there is", "there are", "there were".
- Replace this: You can access Vultr servers from any device, and you get automatic backups and DDOS protection.
- With this: Get automatic backups, DDOS protection, and access Vultr servers from any device.
Use a Grammar Checker
Grammar-check software isn't perfect, but it can flag a lot of issues for review. MS Word and Grammarly are two popular options.
Thank you for contributing to our document collection! We aim to be a high-quality resource for the entire Vultr community. If you see an error in our documentation, please use the Suggest an update button at the bottom of every Vultr Doc. If you have a question about the Vulr Docs program, please contact us. We appreciate your feedback.
Want to contribute?
You could earn up to $300 by adding new articles