DeployHQ Frequently Asked Questions

Last updated on 1st October 2025

General Deployment Concepts

  • What does "deployment" mean in software? Software deployment is all of the activities that make a software system available for use. These activities can span from moving code from a repository to a server, to performing build operations on your code and setting up applications for end users.

  • What does it mean to deploy a project? Deploying a project involves taking your finished code and making it operational on a server, allowing users to access and interact with your website or application. In DeployHQ, a project is where you can configure your deployment strategy and any details needed to make your deployment your own.

  • What does it mean to deploy code? Deploying code is the action of taking your code from your repository, and making it available for usage in a server, either for development, testing, staging or production purposes.

  • What is the difference between hosting and deployment? Hosting refers to where your website or application is stored and served from, while deployment is the process of updating or publishing your code to that hosting environment.

  • What are the 5 steps of deployment? While specific steps may vary, a typical deployment process includes: planning, development, testing, deployment, and monitoring/maintenance. DeployHQ takes care of the 4th step in this process, the deployment step.

  • What are the 3 deployment models? Common deployment models include on-premises deployment, cloud-based deployment, and hybrid deployment. With DeployHQ, you can deploy to all 3 models in this case, as long as you can connect your server with our system.

  • What are the 4 types of hosting? There are 4 types of hosting widely used to deploy applications and websites: Shared Hosting, Virtual Private Servers (VPS), Dedicated Servers and Cloud Hosting. DeployHQ allows you to deploy to all 4 types by offering a flexible connection system with all types of hosting solutions.

  • What are the advantages of using a deployment tool like DeployHQ over manual methods (e.g., FTP/SSH)? Using a deployment tool like DeployHQ offers several advantages over manual methods:

    • Automation: Reduces repetitive manual work and the chance of human error.
    • Speed: Faster deployments through optimized processes.
    • Consistency: Ensures the same deployment process is followed every time.
    • Version Control Integration: Seamlessly deploys from Git repositories, allowing easy rollbacks to previous versions.
    • Build Processes: Can automate build steps (e.g., compiling assets, running tests) before deployment.
    • Configuration Management: Helps manage different configurations for various environments (staging, production).
    • Logging and History: Provides a record of all deployments for auditing and troubleshooting.
    • Collaboration: Allows teams to manage and monitor deployments from a central place.

  • What's the difference between Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment? How does DeployHQ fit into this workflow?

    • Continuous Integration (CI): Developers frequently merge their code changes into a central repository, after which automated builds and tests are run.
    • Continuous Delivery (CD): Extends CI by automatically releasing software that passes all tests to a repository or a staging environment. Deployment to production is often a manual step.
    • Continuous Deployment (CD): Goes one step further than Continuous Delivery by automatically deploying every change that passes through the production pipeline to production. DeployHQ primarily focuses on the deployment aspect. It can be a crucial part of a Continuous Delivery or Continuous Deployment pipeline, taking the code (which might have been built and tested by a CI server) and deploying it to various environments. DeployHQ's automatic deployments can help achieve Continuous Deployment.

  • What are some common deployment strategies (e.g., blue/green, canary) and can DeployHQ facilitate them? Common deployment strategies include:

    • Blue/Green Deployment: Maintaining two identical production environments ("blue" and "green"). Deployments happen to the inactive environment, which is then switched to become the live one.
    • Canary Deployment: Gradually rolling out the new version to a small subset of users before making it available to everyone.
    • Rolling Deployment: Slowly replacing instances of the old version with the new version one by one or in batches.

    A tool like DeployHQ can facilitate these strategies by allowing you to define multiple server environments and control which environment is targeted by a deployment. Specific support for advanced strategies like automated traffic switching for blue/green would depend on DeployHQ's advanced features or integrations. Please refer to DeployHQ's documentation for more details.

Using DeployHQ

  • What is DeployHQ? DeployHQ is a powerful deployment platform that automates and simplifies the process of deploying websites and applications from your repositories to your servers. It has some very handy tools to make deployments easier, such as Build pipelines, Automatic deployments, Deployment templates, etc. More on these features can be found here.

  • How do I start a deployment in DeployHQ? To start a deployment in DeployHQ, connect your repository, configure your server settings, and click the "Deploy" button in the DeployHQ dashboard. For more detailed instructions, you can check our article on how to make your first deployment with DeployHQ.

  • How do I deploy my code/site? With DeployHQ, you can deploy your app or site by connecting your repository, configuring your server settings, and initiating a deployment. For detailed instructions, please refer to our documentation. DeployHQ also offers multiple ways to deploy code, including automatic deployments triggered by repository changes and manual deployments initiated through our user interface.

  • How do I deploy in a server? DeployHQ supports deployment to various server types and protocols. Simply configure your server settings in DeployHQ, and our platform will handle the deployment process for you. You can also check our currently documented hosting providers.

  • Can you use git for deployments? You can definitely use Git for deployment purposes! Learn more about deploying websites with Git here. DeployHQ is designed to work seamlessly with Git repositories.

  • What are "build pipelines" in DeployHQ and why would I use one? Build pipelines in DeployHQ allow you to define a series of commands that run before your code is deployed. This is useful for tasks like:

    • Installing dependencies (e.g., npm install, composer install)
    • Compiling assets (e.g., Sass to CSS, JavaScript minification)
    • Running tests
    • Building a production version of your application

    You would use a build pipeline to automate these necessary pre-deployment steps, ensuring your code is correctly prepared before it goes live. Check DeployHQ's features page for more information on how to configure them.

  • How do "Automatic Deployments" work in DeployHQ, and what triggers them? Automatic deployments in DeployHQ typically monitor your connected Git repository. When changes are pushed to a specific branch (e.g., main, master, or a custom branch), DeployHQ can automatically trigger a deployment to your configured server. This helps in achieving Continuous Deployment or Continuous Delivery workflows. You can usually configure the specific branch and other conditions for automatic deployments within your project settings in DeployHQ.

  • Can I manage environment-specific configurations (e.g., database credentials for staging vs. production) with DeployHQ? If so, how? Yes, managing environment-specific configurations is a common requirement. Deployment tools like DeployHQ often provide ways to handle this, such as:

    • Environment Variables: Allowing you to set variables within DeployHQ that are then available during the deployment process or injected into your application.
    • Configuration Files: Deploying different configuration files based on the target environment.
    • Build Script Logic: Using your build pipeline to generate or select the correct configuration at deployment time.

    Please refer to the DeployHQ documentation for specific details on managing environment configurations.

  • Does DeployHQ support deployment to serverless platforms or containerized environments (e.g., AWS Lambda, Docker, Kubernetes)? DeployHQ's core functionality is often focused on deploying to servers via protocols like SSH/SFTP, FTP, etc. Support for serverless platforms (like AWS Lambda, Azure Functions) or container orchestration systems (like Docker Swarm or Kubernetes) would depend on specific integrations or features. You would need to check DeployHQ's documentation and guides to see if they offer direct support or if you can use build commands to interact with the APIs of these platforms.

  • What kind of notifications can DeployHQ send regarding deployment status (e.g., success, failure)? Deployment tools like DeployHQ typically offer notifications to keep you informed about the status of your deployments. Common notification channels include:

    • Email notifications
    • Integrations with team chat applications (e.g., Slack, Microsoft Teams)
    • Webhook notifications to custom systems These notifications usually cover events like deployment success, failure (with error details), and sometimes a summary of changes. Check your DeployHQ project settings or their features page for available notification options.

  • How does DeployHQ handle rollbacks if a deployment fails or introduces issues? DeployHQ, leveraging Git, makes rollbacks straightforward. Since each deployment typically corresponds to a Git commit, rolling back often involves redeploying a previous, stable commit. DeployHQ usually provides an interface to view deployment history and re-deploy an older version quickly. More advanced rollback strategies might involve specific scripts or server configurations.

  • Can I schedule deployments for specific times with DeployHQ? Some deployment tools offer the ability to schedule deployments for specific times, which can be useful for deploying during off-peak hours. Check the DeployHQ features list or your project settings to see if scheduled deployments are supported.

  • Does DeployHQ offer features for team collaboration (e.g., multiple users, permissions)? Most professional deployment tools, including DeployHQ, offer features for team collaboration. This typically includes:

    • Adding multiple users to an account or project.
    • Role-based access control or permissions to restrict what users can do (e.g., who can deploy to production).
    • Audit logs to see who performed which actions. Details on team management features can be found on DeployHQ's pricing or features page.

  • What is "zero-downtime deployment" and can DeployHQ help achieve it? Zero-downtime deployment is a strategy that allows you to update an application without any user-facing interruption in service. This often involves techniques like blue/green deployments, rolling updates, or canary releases. While DeployHQ handles the code transfer and execution of commands, achieving true zero-downtime often requires specific server setup and load balancing. DeployHQ can facilitate the process by allowing you to deploy to different server sets or trigger scripts that manage traffic switching, but the underlying infrastructure for zero-downtime needs to be in place.

  • How can I manage database migrations or other pre/post-deployment tasks with DeployHQ? DeployHQ's build pipeline feature is designed for this. You can add commands to your build pipeline to:

    • Run database migrations: php artisan migrate, rake db:migrate, etc. (before the new code is live).
    • Clear caches: After deployment.
    • Restart application servers: If necessary.
    • Any other script or command needed before or after the code files are updated. These commands can be configured to run at specific stages of the deployment process.

  • What version control systems (besides Git) does DeployHQ integrate with, if any? While DeployHQ's primary focus and tightest integration is with Git (supporting providers like GitHub, GitLab, Bitbucket, or self-hosted Git repositories), you should check their official documentation for support for other VCS like Subversion or Mercurial. However, Git is the industry standard for modern web development.

  • Are there any limitations on repository size or project complexity with DeployHQ? Most SaaS platforms have some limitations, which could be related to repository size, number of files, deployment duration, or build process resources, often tied to the subscription plan. For specific limitations, it's best to consult DeployHQ's pricing page or their terms of service.

  • How secure is DeployHQ? DeployHQ takes security seriously. We use encryption for data in transit and at rest, employ secure protocols, and regularly perform security audits. As for account security, we offer various methods to secure your account, you can read more on your options in this article.

  • How does DeployHQ handle SSH keys and other sensitive credentials for server access? Secure handling of credentials is vital. Deployment services like DeployHQ typically:

    • Store SSH private keys and other sensitive data encrypted at rest.
    • Use secure protocols (SSH/SFTP) for server communication.
    • Provide mechanisms for managing server credentials within their interface, avoiding the need to store them in your repository. For DeployHQ's specific security measures regarding credentials, refer to their security documentation or support.

Support and Pricing

  • Can I deploy a app/website for free? While DeployHQ is a paid service, we do offer both a free tier with a limited amount of daily deployments, and a free trial. You can check all our options in our pricing page.

  • What kind of support does DeployHQ offer? DeployHQ offers comprehensive documentation, email support, and priority support for higher-tier plans.

  • What happens if I exceed the deployment limits on the free tier or my plan? Typically, if you exceed limits (e.g., number of deployments, build minutes) on a free tier or a specific plan, further deployments might be temporarily blocked until the limit resets (e.g., daily or monthly) or until you upgrade your plan. For DeployHQ's specific policies, please check their pricing page details or contact their support.

Troubleshooting

  • What common issues can arise during deployment, and how can I prepare for or troubleshoot them (perhaps generally, with a hint of how DeployHQ helps)? Common deployment issues include:

    • Permission errors: The deployment user lacks necessary write permissions on the server.
    • Incorrect paths: Configuration pointing to wrong directories.
    • Dependency issues: Missing PHP extensions, incorrect Node.js versions, etc.
    • Build failures: Errors in compilation, tests failing.
    • Database connection problems: Incorrect credentials or network issues.
    • Full disk space: Server running out of storage. To prepare:
    • Ensure consistent environments (development, staging, production).
    • Test deployments in a staging environment first.
    • Have a rollback plan. DeployHQ helps by providing detailed deployment logs, which are crucial for identifying the cause of failures. Its build pipeline can also run pre-flight checks or tests.

Beta Features & Cloud Platforms

  • What are beta features in DeployHQ? Beta features are experimental new features and integrations that are available for testing before they become generally available. These features may change based on user feedback and are enabled account-wide through your account settings.

  • How do I enable beta features? To enable beta features:

    1. Navigate to Settings → Account → Beta Features
    2. Toggle the switch to enable beta functionality
    3. Click "Save Changes" to apply the setting
    4. All users in your account will then have access to beta features

  • What cloud platforms does DeployHQ support? DeployHQ currently supports several cloud platforms as beta features:

    • Netlify: For static sites and single-page applications (React, Vue, Angular, etc.)
    • Heroku: For web applications using the Heroku Platform API
    • AWS Elastic Beanstalk: For scalable web applications on AWS
    • Traditional server deployment via SSH/SFTP/FTP protocols

  • How is cloud platform deployment different from traditional FTP/SSH deployment? Cloud platform deployments use platform-specific APIs and packaging:

    • Traditional deployment: Transfers individual files via FTP/SSH/SFTP
    • Cloud deployment: Creates application packages and uses platform APIs for deployment
    • Build integration: Cloud platforms often handle builds automatically or use packaged builds
    • Scaling: Cloud platforms typically offer automatic scaling and load balancing

  • Can I deploy the same project to both traditional servers and cloud platforms? Yes! You can configure multiple servers for the same project, allowing you to deploy to both traditional servers (via SSH/FTP) and cloud platforms (Netlify, Heroku, etc.) simultaneously or as needed.

  • What are the requirements for deploying to Netlify? To deploy to Netlify through DeployHQ:

    • Beta features must be enabled in your account
    • You need a Netlify personal access token
    • An existing Netlify site with the site ID
    • Your project should be built (React, Vue, Angular, static sites, etc.)
    • DeployHQ will deploy the build output to your Netlify site

  • What are the requirements for deploying to Heroku? To deploy to Heroku through DeployHQ:

    • Beta features must be enabled in your account
    • A Heroku API key for authentication
    • An existing Heroku application
    • Your project should include appropriate configuration files (package.json, requirements.txt, etc.)

  • What are the requirements for deploying to AWS Elastic Beanstalk? To deploy to AWS Elastic Beanstalk through DeployHQ:

    • Beta features must be enabled in your account
    • AWS credentials with appropriate Elastic Beanstalk permissions
    • An existing Elastic Beanstalk application and environment
    • Your project configured according to Elastic Beanstalk requirements

  • Are beta features stable for production use? Beta features are experimental and may change based on feedback. While we strive for stability:

    • Test thoroughly in non-production environments first
    • Have backup deployment methods available
    • Monitor deployments closely when using beta features
    • Be prepared for potential changes in functionality or interface

  • Can I provide feedback on beta features? Yes! We encourage feedback on beta features:

    • Report issues through our support system
    • Share suggestions for improvements
    • Tell us about your usage patterns and experience
    • Your feedback helps shape the final implementation

API Access & Restrictions

  • Why can't I access the DeployHQ API? API access is restricted by pricing plan as of September 2025. Not all plans include API access, and some accounts may have API access disabled.

  • Which pricing plans include API access? API access availability varies by plan:

    • Free plans: Typically do not include API access
    • Paid plans: Most include API access, but check your specific plan
    • Enterprise plans: Full API access included
    • Check your account settings or contact support to confirm your plan's API access

  • How do I check if my account has API access? To verify your API access:

    • Go to Settings → Account → API section
    • Look for API access status indicators
    • Try accessing the API documentation in your account
    • Check your billing/plan details for API access inclusion

  • What happens if I try to use the API without access? If you attempt to use the API without proper access:

    • API calls will be blocked with authentication errors
    • You'll receive error messages indicating insufficient permissions
    • Activity logs will record blocked API access attempts
    • You'll need to upgrade your plan or contact support

  • Can I upgrade my plan to get API access? Yes, you can upgrade to a plan that includes API access:

    • Go to Settings → Billing → Change Package
    • Select a plan that includes API access
    • The upgrade typically takes effect immediately
    • Existing API tokens will become active once access is enabled

  • Are there rate limits on the API? Yes, the DeployHQ API has rate limits to ensure fair usage:

    • Limits vary by endpoint and account type
    • Rate limiting helps maintain service performance
    • Check the API documentation for specific limits
    • Contact support if you need higher rate limits

  • What can I do with the DeployHQ API? The API allows you to:

    • Create and manage deployments programmatically
    • Access deployment history and logs
    • Manage projects, servers, and configurations
    • Integrate DeployHQ with your CI/CD pipelines
    • Automate deployment workflows

  • How do I get API credentials? To get API access:

    • Ensure your plan includes API access
    • Go to Settings → API section in your account
    • Generate API tokens with appropriate permissions
    • Use these tokens for API authentication
    • Keep tokens secure and rotate them regularly

Integration Management

  • What are integrations in DeployHQ? Integrations are third-party services that connect with DeployHQ to provide notifications, monitoring, and additional functionality during your deployment process. They can send notifications about deployment status, clear caches, or perform other automated tasks.

  • What integrations are available in DeployHQ? DeployHQ offers a wide range of integrations:

    • Notifications: Slack, Discord, Microsoft Teams, Email
    • Monitoring & Error Tracking: New Relic, Rollbar, Sentry, Bugsnag, Honeybadger
    • Services: Shopify (cache clearing), Cloudflare (cache purging)
    • Custom: HTTP POST webhooks for custom integrations

  • How do I reorder integrations? You can control the execution order of integrations:

1. Navigate to your project's integrations page
2. Use the drag handle (reorder icon) next to each integration
3. Drag integrations up or down to change their execution order
4. The new order is saved automatically
5. Integrations execute from top to bottom during deployments

  • Why would I want to change integration execution order? Integration order matters for certain workflows:

    • Cache clearing before notifications: Clear Shopify/Cloudflare cache before sending success notifications
    • Error tracking before alerts: Set up error monitoring before other notifications
    • Sequential dependencies: Some integrations may depend on others completing first
    • Priority notifications: Send critical alerts before informational ones

  • Can I disable integrations temporarily? Yes, most integrations can be disabled without deletion:

    • Edit the integration settings
    • Look for an "enabled" or "active" toggle
    • Disable temporarily and re-enable when needed
    • This preserves your configuration while pausing execution

  • When do integrations execute during deployment? Integrations can execute at different stages:

    • Pre-deployment: Before files are transferred (less common)
    • Post-deployment: After successful deployment (most common)
    • On failure: When deployments fail (error notifications)
    • Custom triggers: Based on specific conditions or webhooks

  • How do I set up Slack notifications? To integrate with Slack:

1. Go to your project's integrations section
2. Add a new Slack integration
3. Configure your Slack webhook URL
4. Choose notification triggers (success, failure, started)
5. Customize message format and channels
6. Test the integration to verify it works
  • How do I set up error tracking integrations? For services like Sentry, Rollbar, or Bugsnag: 
1. Ensure you have an account with the error tracking service
2. Get your API key or access token from the service
3. Add the integration in DeployHQ
4. Configure which events trigger the integration
5. Test to ensure error data is being sent correctly

  • Can I create custom integrations? Yes, using HTTP POST webhooks:

    • Set up an HTTP POST integration
    • Configure your endpoint URL
    • Define custom payload data
    • Set authentication headers if needed
    • Use this to integrate with any service that accepts webhooks

  • What information is sent to integrations? Integration payloads typically include:

    • Deployment status (success, failure, started)
    • Project and server information
    • Deployment logs and error messages
    • User who triggered the deployment
    • Timestamp and deployment duration
    • Links to view full deployment details

  • How do I troubleshoot integration failures? If integrations aren't working:

    • Check the integration configuration and credentials
    • Verify the external service is accessible
    • Review deployment logs for integration error messages
    • Test the integration manually if possible
    • Check rate limits or quotas on the external service
    • Contact support if issues persist

Build Pipeline Specifics

  • What are build pipelines in DeployHQ? Build pipelines are a series of commands that run before your code is deployed to servers. They allow you to automate tasks like installing dependencies, compiling assets, running tests, and preparing your application for deployment.

  • What build tools and languages are supported? DeployHQ supports a wide range of build tools and languages:

    • JavaScript/Node.js: npm, yarn, pnpm, bun, webpack, gulp, grunt
    • PHP: Composer, Laravel Mix
    • Python: pip, pipenv, poetry
    • Ruby: Bundler, Rails asset compilation
    • Static Sites: Jekyll, Hugo, Gatsby
    • Rust: Cargo
    • Java: Maven
    • Go, .NET, and many others

  • How do I set up a build pipeline? To configure a build pipeline:

1. Go to your project settings in DeployHQ
2. Navigate to the "Build Pipeline" section
3. Add build commands in the order they should execute
4. Specify any environment variables needed
5. Save your configuration
6. Test with a deployment to ensure it works

  • What are common build pipeline commands? Popular build commands include:

    • Install dependencies: npm install, composer install, pip install -r requirements.txt
    • Build assets: npm run build, npm run production
    • Run tests: npm test, phpunit, pytest
    • Compile: cargo build --release, mvn package
    • Generate static sites: gatsby build, hugo, jekyll build

  • How do I troubleshoot build failures? When builds fail:

1. Check the build logs in the deployment details
2. Verify all required dependencies are listed in your project files
3. Ensure environment variables are correctly configured
4. Test build commands locally in the same environment
5. Check for version compatibility issues
6. Review [language-specific troubleshooting guides](Article: #283)

  • What are build allowances? Build allowances are limits on build resources:

    • Monthly build minutes included in your plan
    • Build time limits per individual build
    • Concurrent build limits
    • Storage limits for build artifacts
    • Check your plan details for specific allowances

  • Can I use custom Docker containers for builds? Build environments are managed by DeployHQ:

    • Standard build environments include common tools and language runtimes
    • You can specify language versions in many cases
    • Custom Docker containers are not currently supported
    • Contact support if you need specific tools or configurations

  • How do I handle different build requirements for different servers? You can configure server-specific build commands:

    • Use conditional logic in build scripts
    • Create environment-specific configuration files
    • Use different branches for different environments
    • Configure separate projects for different deployment targets
    • Check our server-specific build pipeline guide

  • Can I cache build dependencies? Yes, DeployHQ supports build caching:

    • Common dependency directories are cached automatically (node_modules, vendor, etc.)
    • Cache persists between builds to speed up subsequent deployments
    • Cache can be cleared if needed through build settings
    • See our build caching guide for more details

  • How long can builds take? Build time limits depend on your plan:

    • Free plans typically have shorter build time limits
    • Paid plans allow longer build times
    • Very complex builds may hit time limits
    • Optimize builds using caching and parallel processing where possible

  • Can I run tests in my build pipeline? Yes, running tests is a common practice:

    • Add test commands to your build pipeline
    • Builds will fail if tests don't pass, preventing deployment
    • This helps catch issues before they reach your servers
    • Configure test reporting and notifications as needed

Security & Best Practices

  • How does DeployHQ handle SSH keys and server credentials? DeployHQ takes security seriously when handling sensitive credentials:

    • SSH private keys are stored encrypted at rest
    • All server communication uses secure protocols (SSH/SFTP)
    • Credentials are never stored in plain text
    • Access to credentials is restricted to authorized deployment processes
    • Regular security audits ensure best practices are maintained

  • What are the security best practices for DeployHQ? Follow these practices to keep your deployments secure:

    • Enable two-factor authentication on your DeployHQ account
    • Use strong, unique passwords for your account
    • Regularly rotate server credentials and SSH keys
    • Limit server access to only necessary IP addresses
    • Monitor deployment logs for unusual activity
    • Keep your repository access tokens up to date and secure

  • How do I enable two-factor authentication? To secure your account with 2FA:

1. Go to Settings → Security Settings
2. Navigate to Two-Factor Authentication section
3. Follow the setup process using your preferred authenticator app
4. Save backup codes in a secure location
5. Test the setup to ensure it works correctly
6. See our [2FA guide](Article: #181) for detailed instructions

  • What IP ranges does DeployHQ use for deployments? DeployHQ deploys from specific IP ranges:

    • Check our IP ranges documentation for current addresses
    • Add these IPs to your server's allowlist if you use IP restrictions
    • IP ranges may be updated periodically for infrastructure improvements
    • Subscribe to updates to be notified of any changes

  • How do I secure my server for DeployHQ access? Best practices for server security:

    • Use SSH key authentication instead of passwords
    • Disable root login and use a dedicated deployment user
    • Restrict SSH access to DeployHQ IP ranges only
    • Use strong file permissions on your web directories
    • Keep your server software updated with security patches
    • Monitor server logs for unauthorized access attempts

  • Should I use a dedicated user for deployments? Yes, using a dedicated deployment user is recommended:

    • Create a user specifically for DeployHQ deployments
    • Grant only necessary permissions to web directories
    • Don't give the deployment user sudo privileges unless required
    • Use SSH key authentication for this user
    • This limits potential damage if credentials are compromised

  • How do I keep my repository access secure? Repository security best practices:

    • Use deploy keys instead of personal access tokens when possible
    • Limit repository permissions to read-only if write access isn't needed
    • Regularly audit repository access and remove unused keys
    • Use different keys for different services and environments
    • Monitor repository activity for unauthorized access

  • What should I do if I suspect a security issue? If you notice suspicious activity:

1. **Immediately change your passwords** and rotate SSH keys
2. **Review recent deployment logs** for unauthorized deployments
3. **Check server logs** for unusual access patterns
4. **Contact DeployHQ support** immediately to report the issue
5. **Update repository access tokens** and review permissions
6. **Monitor your systems** closely for any ongoing issues

  • How do I audit my deployment security? Regular security audits should include:

    • Review user access and remove inactive users
    • Check SSH key usage and remove old or unused keys
    • Audit server permissions and file access rights
    • Review integration settings and API access
    • Monitor deployment logs for unusual patterns
    • Verify 2FA is enabled for all team members

  • What data does DeployHQ store and how is it protected? DeployHQ stores:

    • Account information: Encrypted and access-controlled
    • Repository credentials: Encrypted at rest and in transit
    • Server credentials: Encrypted with industry-standard algorithms
    • Deployment logs: Temporarily stored for troubleshooting
    • Project configurations: Secured with role-based access
    • All data is protected with encryption and regular backups

Migration & Platform Changes

  • How do I migrate from DeployBot to DeployHQ? DeployBot and DeployHQ have merged, making migration straightforward:

    • Most DeployBot features are available in DeployHQ
    • Your projects and configurations can be migrated
    • Follow our migration guide for step-by-step instructions
    • Contact support for assistance with complex migrations
    • Take advantage of improved features and performance in DeployHQ

  • How do I transfer projects between accounts? To transfer a project to another account:

    • Contact DeployHQ support with your transfer request
    • Provide the project details and destination account information
    • Ensure both accounts agree to the transfer
    • Support will handle the transfer process for you
    • See our project transfer guide for more details

  • What happens to my data if I downgrade my plan? When downgrading:

    • Your projects and configurations remain intact
    • You may lose access to premium features
    • Deployment limits may be reduced
    • API access may be restricted based on the new plan
    • Historical data and logs are typically preserved
    • Contact support before downgrading to understand impacts

  • Can I export my deployment data? Data export options:

    • Use the API to export project configurations and deployment history
    • Download deployment logs through the interface
    • Contact support for bulk data exports if needed
    • Most configuration data can be recreated in other platforms
    • Regular backups of critical data are recommended

  • How do I change my account's primary domain? To update your account domain:

    • Go to Settings → Account Configuration
    • Update your domain settings if available
    • Contact support for guidance on domain changes
    • Some changes may require account migration
    • See our custom domain guide for setup instructions

  • What happens during service maintenance? During maintenance periods:

    • Scheduled maintenance is announced in advance
    • Deployments may be temporarily unavailable
    • Your configurations and data remain safe
    • Emergency maintenance may occur with minimal notice
    • Status updates are provided during maintenance windows

  • How do I migrate from other deployment services? Migrating from other platforms:

    • Review your current deployment configuration
    • Set up equivalent projects and servers in DeployHQ
    • Test deployments in a staging environment first
    • Gradually migrate projects to minimize disruption
    • Contact support for assistance with complex migrations

  • Can I use DeployHQ alongside other deployment tools? Yes, you can use multiple deployment tools:

    • Use different tools for different projects or environments
    • Gradually migrate from other tools to DeployHQ
    • Ensure deployment processes don't conflict
    • Consider standardizing on one platform for consistency
    • DeployHQ can often replace multiple specialized tools

If you have other questions, please refer to our full documentation or contact our support team.