DOCSEARCHbyAlgolia
Submit Docs

Seed Serverless Deployment Platform

website·Indexed 33 days ago

https://seed.run/docs/

A deployment platform for Serverless applications that accelerates build and deployment times. Seed supports the Serverless Framework, AWS CDK, and SST, offering features such as incremental Lambda deploys, custom build images, and GitHub integration for managing environments and pull requests.

Tokens
74.7K
Snippets
200
Records
666
Agent score
70%

What's inside Seed

  1. Overview of serverless-bundle v5 features

    The serverless-bundle plugin provides a zero-config method to bundle AWS Lambda functions using Webpack, eliminating the need for manual maintenance of multiple packages or configuration files. Version 5 introduces several key enhancements to build performance and bundle size.

  2. Overview of Seed Native Error Reporting

    Native Error Reporting allows you to report handled exceptions and custom errors to Seed Issues without installing 3rd party SDKs, using wrappers, or making API calls. It has no impact on Lambda performance and works in local environments. Seed automatically detects errors logged to the console/standard error stream.

    Supported Runtimes:

    • Node.js (10.x and above)
    • Python (3.7 and 3.8)

  3. Overview of Seed Issues monitoring

    Issues is a native, real-time Lambda monitoring and alerting service for Serverless apps. It works by asynchronously subscribing to CloudWatch log groups, meaning it requires no code changes, external SDKs, or HTTP calls from within the Lambda function, ensuring no impact on application performance. It autodetects timeouts, out-of-memory errors, and unhandled exceptions. Note: This feature has been phased out in favor of the SST Console.

  4. Overview of Incremental Service Deploys in Seed

    Seed uses Incremental Service Deploys to speed up builds and reduce costs in monorepo Serverless apps. Instead of deploying all services on every commit, Seed checks if a specific service has been updated before triggering its deployment. There are three available algorithms for this check: Git log analysis (default), Lerna, and pnpm.

  5. Auto-deploy pull requests to untracked branches

    Seed is configured to automatically deploy pull requests even if they are submitted to branches that are not explicitly being tracked.

  6. Analyze build performance using detailed build logs

    Seed build logs now include the duration for each individual step in the build process. This allows developers to identify slow steps and optimize their build configuration to reduce overall build time.

  7. Understand Seed App Reports functionality

    Seed App Reports provide a weekly overview of your organization's apps, focusing on Lambda and API metrics such as request volume, latency, and a summary of top issues. Reports are generated every Monday around 2am UTC and are accessible within the organization's settings.

  8. Understand the Seed build and deployment process for SST and Serverless Framework

    Seed decomposes the sst deploy or serverless deploy process into discrete steps to ensure that the exact same artifacts used in a development stage are promoted to production.

    For a commit to a branch (e.g., master) connected to a stage (e.g., dev), the process is:

    1. Target Stage Packaging: A package is created for the target stage using sst build or serverless package.
    2. Production Packaging: A package is created for the production stage (and pre-production if configured). This step is performed asynchronously and does not count toward build minutes. This package is tagged with the Git commit and stored.
    3. Deployment: The target stage is deployed. For Serverless Framework, Seed uses serverless deploy --package. For SST, a custom command is used to deploy the package created in Step 1.

    When promoting a build to production, Seed retrieves the stored package tagged with the specific Git commit to generate a CloudFormation Change Set, ensuring the production environment receives the exact build artifacts verified in earlier stages.

  9. Understand Seed environment variable encryption changes

    Seed has updated how environment variables are stored. Previously, Seed used the customer's AWS KMS keys for encryption, which required expansive AWS permissions and caused decryption failures if stage credentials changed. Seed now encrypts environment variables entirely on its own end using Seed's own KMS credentials. This removes the requirement for users to grant Seed access to their AWS KMS keys.

  10. Monitor Seed build status via GitHub Status Checks

    Seed automatically sends status checks for commits and pull requests to your GitHub repository. This allows developers to monitor the progress and success of Serverless Framework deployments directly within the GitHub UI without needing to switch to the Seed dashboard. These checks are enabled by default for all Seed users and require no manual configuration. To view the detailed build logs, click the 'Details' link associated with the status check in GitHub.

  11. Understand Seed's Serverless Framework versioning and caching

    Seed uses a recent stable release of the Serverless Framework as the default for newly created apps. To prevent breaking changes, Seed does not automatically update the default version for previously deployed apps.

    Seed internally caches versions of the Serverless Framework to speed up builds. If a pinned version is not already cached, Seed adds it to a queue to be cached for future builds. The current version being used can be found at the top of the build logs.

  12. Manage deployed resources in the Seed console

    The Seed console provides a centralized view of all resources deployed within a Serverless app. After deployment, the console displays:

    • A list of all deployed Lambda functions and their corresponding API paths.
    • The API Gateway endpoint and any configured custom domains.
    • CloudFormation stack outputs with a one-click copy mechanism for values.
    • A comprehensive list of all other deployed resources.

    Additionally, the console provides direct links to view Lambda logs and API Gateway Access logs.